From nobody Mon Aug 1 15:24:00 2016 Return-Path: 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 F212812D6A5; Mon, 1 Aug 2016 15:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 r_V4CuhuSa8o; Mon, 1 Aug 2016 15:23:56 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE7F12D918; Mon, 1 Aug 2016 15:23:56 -0700 (PDT) Received: from localhost ([::1]:39768 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bULcp-0001O5-RC; Mon, 01 Aug 2016 15:23:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Mon, 01 Aug 2016 22:23:55 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6 Message-ID: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160801222356.8EE7F12D918@ietfa.amsl.com> Resent-Date: Mon, 1 Aug 2016 15:23:56 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #6 (negotiating-human-language): Coolect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:23:58 -0000 #6: Coolect information on modality in separate section for clarity Introduce a new section on implicit and explicit modality and move modaliy-related information to this section Change 1 _________________________________________________________________________________________________________________ 6.x Implicit and explicit modality The use of the "humintlang-send" and "humintlang-recv" media attributes is supposed to indicate combinations of media stream, modality, favoured level language(s) and preference for each language within the media stream. Spoken and written languages have common language tags. Sign languages have unique language tags. Thus, in many cases, the language tag itself does not indicate modality explicitly. Some media types indicate implicitly the dominating modality used in streams of that media type. Thus, for 'audio' media, the default modality is 'spoken'. For 'video' media, the default modality is 'signed' when using sign language tags and 'spoken' in the form of a view of the speaking person when using spoken/written language tags. For 'text' media, the default modality is 'written'. Other media types, such as 'application' have less obvious relation to any specific modality. Therefore, a "modality" parameter is available in the media attributes for explicit indication of the modality of language use in the indicated media. See the syntax section for syntax description for the modality parameter. The following table indicates the modalities related to the foreseen combinations of media type and language tag types. ----------------------------------------------------------------------------------------------------------------------- |Media type subtype and subprotocol language tag type modality parameter modality |---------------------------------------------------------------------------------------------------------------------- |Audio - spoken or written none or spoken spoken |Video - signed none or signed signed |Video - spoken or written none or spoken spoken (view of speaking person) |Text - spoken or written none or written written |Application webrtc-datachannel(t140) spoken or written written written ----------------------------------------------------------------------------------------------------------------------- Note: The application/webrtc-datachannel subprotocol 't140' is specified in draft-schwarz-mmusic-t140-usage-data-channel. ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------- Change 2: Move the following paragraph from section 6.2 to this new section 6.x: ------------------------------------------------------------------------------ " Note that while signed language tags are used with a video stream to indicate sign language, a spoken language tag for a video stream in parallel with an audio stream with the same spoken language tag indicates a request for a supplemental video stream to see the speaker." ------------------------------------------------------------------------------ Change 3: Delete the following statement from section 6.4. It is the same as above but less clearly stated. ---------------------------------------------------------------------- A spoken language tag for a video stream in conjunction with an audio stream with the same language might indicate a request for supplemental video to see the speaker. ---------------------------------------------------------------------- For discussion on this issue: If text embedded as captions in video is a modality that should be covered, then one line with explicit modality = "written" needs to be added to the table above. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Keywords: modality Severity: In WG Last Call | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 1 15:24:57 2016 Return-Path: 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 9EFF712D661; Mon, 1 Aug 2016 15:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 KFXtRmyip1ig; Mon, 1 Aug 2016 15:24:54 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AB112D9B1; Mon, 1 Aug 2016 15:24:43 -0700 (PDT) Received: from localhost ([::1]:39787 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bULdb-0003Z3-E3; Mon, 01 Aug 2016 15:24:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Mon, 01 Aug 2016 22:24:43 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:1 Message-ID: <082.1f3d5e44b03868e3613388e698fba896@tools.ietf.org> References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160801222443.B8AB112D9B1@ietfa.amsl.com> Resent-Date: Mon, 1 Aug 2016 15:24:43 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity (was: Coolect information on modality in separate section for clarity) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:24:55 -0000 #6: Collect information on modality in separate section for clarity -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 1 15:31:26 2016 Return-Path: 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 609C212D827; Mon, 1 Aug 2016 15:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 B1PLy2p6Wexv; Mon, 1 Aug 2016 15:31:24 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C5412D7B4; Mon, 1 Aug 2016 15:31:23 -0700 (PDT) Received: from localhost ([::1]:40119 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bULk3-0000ui-MB; Mon, 01 Aug 2016 15:31:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Mon, 01 Aug 2016 22:31:23 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:2 Message-ID: <082.bb0327464f607ed1365ae056e79ad640@tools.ietf.org> References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160801223123.F2C5412D7B4@ietfa.amsl.com> Resent-Date: Mon, 1 Aug 2016 15:31:23 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:31:25 -0000 #6: Collect information on modality in separate section for clarity Comment (by gunnar.hellstrom@omnitor.se): Sorry, the table got unreadable. I will need to edit it. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Tue Aug 2 00:32:19 2016 Return-Path: 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 715B512B004; Tue, 2 Aug 2016 00:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 2i7YOIDhmuBW; Tue, 2 Aug 2016 00:32:15 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69610128E18; Tue, 2 Aug 2016 00:32:15 -0700 (PDT) Received: from localhost ([::1]:57275 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bUUBS-0000tW-Ei; Tue, 02 Aug 2016 00:32:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Tue, 02 Aug 2016 07:32:14 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:3 Message-ID: <082.3db92fd61bfc8c1cf8daeeb8c070f349@tools.ietf.org> References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160802073215.69610128E18@ietfa.amsl.com> Resent-Date: Tue, 2 Aug 2016 00:32:15 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 07:32:18 -0000 #6: Collect information on modality in separate section for clarity Comment (by gunnar.hellstrom@omnitor.se): New edit of the table: ||Media type||subtype and subprotocol||language tag type||modality parameter||modality|| ||Audio||-||spoken or written||none or spoken||spoken|| ||Video||-||signed||none or signed||signed|| ||Video||-||spoken or written||none or spoken||spoken (view of speaking person)|| ||Text||-||spoken or written||none or written||written|| ||Application||webrtc-datachannel(t140)||spoken or written||written||written|| -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Tue Aug 2 01:02:57 2016 Return-Path: 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 14FEE12B035; Tue, 2 Aug 2016 01:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 F2ktlstg9Zck; Tue, 2 Aug 2016 01:02:54 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4B812B026; Tue, 2 Aug 2016 01:02:54 -0700 (PDT) Received: from localhost ([::1]:57970 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bUUf7-00083x-W0; Tue, 02 Aug 2016 01:02:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Tue, 02 Aug 2016 08:02:53 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/7 Message-ID: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160802080254.BE4B812B026@ietfa.amsl.com> Resent-Date: Tue, 2 Aug 2016 01:02:54 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 08:02:56 -0000 #7: The notation for Advisory vs Required is not logical and needs revision In section 6.3 of version -04, the Advisory vs required feature is described. The description indicates that it is a session level feature influencing the acceptance or rejection of the call depending on outcome of the language negotiation. The proposed notation in the draft is however hooked on to any media level attribute. This is not logical. Here is instead a session level attribute proposed. Also, the description indicates that the most common result should be to connect the call even if the language negotiation fails, but the notation in the draft has failing the call as default value. This is proposed to be reverted. Change 1: Replace the last paragraph in section 6.3, that currently is: --------------------------------------------------------------- The mechanism for indicating this preference is that, in an offer, if the last character of any of the 'humintlang-recv' or 'humintlang- send' values is an asterisk, this indicates a request to not fail the call (similar to SIP Accept-Language syntax). Either way, the called party MAY ignore this, e.g., for the emergency services use case, a PSAP will likely not fail the call. ------------------------------------------------------------------- replace with: ------------------------------------------------------------------- The mechanism for indicating this preference is a session level attribute "humintlang-disposition", with "reject" and "connect" as possible values and "connect" as default. Example: humintlang-disposition: reject The called party MAY ignore this, e.g., for the emergency services use case, a PSAP will likely not fail the call. ------------------------------------------------------------------- Change 2: -------------------------------------------------------------------- In section 6.2, delete this paragraph since the feature is no longer tied to the humintlang-send or humintlang-recv attributes. ----------------------------------------- In an offer, each language tag value MAY have an asterisk appended as the last character (after the registry value). The asterisk indicates a request by the caller to not fail the call if there is no language in common. See Section 6.3 for more information and discussion. --------------------------------------------------------------- Change 3: Include the syntax of the "humintlang-disposition" in the syntax chapter and examples. - will be submitted separately. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Keywords: reject Severity: In WG Last Call | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 8 23:50:40 2016 Return-Path: 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 32BB812B026; Mon, 8 Aug 2016 23:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 E-gjsWOMENJG; Mon, 8 Aug 2016 23:50:37 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3B212B00A; Mon, 8 Aug 2016 23:50:37 -0700 (PDT) Received: from localhost ([::1]:50444 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bX0s1-00019I-18; Mon, 08 Aug 2016 23:50:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Tue, 09 Aug 2016 06:50:36 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:1 Message-ID: <082.6cbababa93e825f163e92644f6e9d826@tools.ietf.org> References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160809065037.DB3B212B00A@ietfa.amsl.com> Resent-Date: Mon, 8 Aug 2016 23:50:37 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 06:50:39 -0000 #7: The notation for Advisory vs Required is not logical and needs revision Comment (by gunnar.hellstrom@omnitor.se): Modify the text in change 1 to: The mechanism for indicating this preference is a session level attribute "humintlang-disposition", with "reject", "improve" and "connect" as possible values and "connect" as default. Example: a=humintlang-disposition: reject The called party MAY ignore the "reject" value, e.g., for the emergency services use case, a PSAP will likely not fail the call. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: reject | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Tue Aug 9 00:03:40 2016 Return-Path: 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 ABF9B12B014; Tue, 9 Aug 2016 00:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 2k8TokwvTO7B; Tue, 9 Aug 2016 00:03:36 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21410128B44; Tue, 9 Aug 2016 00:03:36 -0700 (PDT) Received: from localhost ([::1]:50607 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bX14Z-0002rX-Gq; Tue, 09 Aug 2016 00:03:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Tue, 09 Aug 2016 07:03:35 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/8 Message-ID: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160809070336.21410128B44@ietfa.amsl.com> Resent-Date: Tue, 9 Aug 2016 00:03:36 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 07:03:38 -0000 #8: Introduce a section on most favoured modality In order to have an opportunity to start the call in the most suitable modality, an indication of most favoured modality is needed together with the language indications. Introduce a new section on that topic. Without this, the answering part is left without a clue about how to start the call. Text for new section in chapter 6 ----------------------------------------------------------------- 6.y Most favoured modality In order to successfully start a call, the parties need to be aware of which language capabilities were negotiated, and also which modality the parties prefer to use. A call can start without hesitation and be conducted smoothly only when answered with the modality and language that best matches the most favoured combinations by the caller. There is a tendency among call participants to continue using the modality first used in a call, even if that is not the most favoured modality. The call participants usually want to communicate about the topic of the call, and not about how the call will be performed. Therefore, a mechanism is provided for indication of most preferred modality/modalities of the call participants together with the language attributes. The mechanism provides a "favoured" modality parameter that MAY be included in the "humintlang-send" and "humintlang-recv" attribute values on media level. The "favoured" modality parameter is a keyword parameter with the name "favoured" and values "most" and "complement". This parameter is intended to be optionally included once for each combination of media, modality and direction of language. The indication is intended to carry the information that that combination is the highest favoured alternative if the value is "most", and is a highly favoured complement to the most favoured modality in another media description if the value is "complement". The value "most" is allowed for more than one media/modality/direction combination for cases when it is essential for the indicating party to use more than one modality in the same direction. The "complement" value SHOULD not be used without any "most" value in the sdp, and should only be used for cases when the modality it is used with is supposed to be used for language transfer simultanously with the corresponding most favoured modality. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Keywords: modality Severity: In WG Last Call | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Tue Aug 9 01:49:53 2016 Return-Path: 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 B912F12D0CE; Tue, 9 Aug 2016 01:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 ThRuMOMaVtDY; Tue, 9 Aug 2016 01:49:49 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B07112B02A; Tue, 9 Aug 2016 01:49:49 -0700 (PDT) Received: from localhost ([::1]:52980 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bX2jM-0006OW-HU; Tue, 09 Aug 2016 01:49:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Tue, 09 Aug 2016 08:49:48 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/9 Message-ID: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160809084949.6B07112B02A@ietfa.amsl.com> Resent-Date: Tue, 9 Aug 2016 01:49:49 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 08:49:52 -0000 #9: Attribute specifications following the layout required by RFC4566bis The attribute specifications need to be more formal than in the current draft (-04 ) The following is required from attribute specifications according to RFC 4566bis, section 8.2.4.1: "New attribute registrations are accepted according to the "Specification Required" policy of [RFC5226], provided that the specification includes the following information: o Contact Name. o Contact Email Address. o Attribute Name: The name of the attribute that will appear in SDP). This MUST conform to the definition of . o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF definition of the attribute value syntax (See Section Section 9) MUST be provided. The syntax MUST follow the rule form as per Section 2.2 of [RFC5234]. This SHALL define the allowable values that the attribute might take. It MAY also define an extension method for the addition of future values. For a property attribute, the ABNF definition is omitted as the property attribute takes no values. o Attribute Semantics: For a value attribute, a semantic description of the values that the attribute might take MUST be provided. The usage of a property attribute is described under purpose below. o Attribute Value: The name of an ABNF syntax rule defining the syntax of the value. Absence of a rule name indicates that the attribute takes no values. Enclosing the rule name in "[" and "]" indicates that a value is optional. o Usage Level: Usage level(s) of the attribute. One or more of: session, media, source, dcsa, dcsa(subprotocol). For a definition of source level attributes, see [RFC5576]. For a definition of dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. o Charset Dependent: Whether the attribute value is subject to the charset attribute or not (Yes/No). o Purpose: An explanation of the purpose and usage of the attribute. o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. o Mux Category: Indication of which multiplexing "category" [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated with. o Reference: A reference to the specification defining the attribute. " --------------------------------------------------------------- Change. Add chapters on the attributes in the format described in RFC4566bis, section 8.2.4.1 Some changes are also needed in the earlier text in the draft to align with these attribute specifications. -------------------------------------------------------------------- x. Specification of the "humintlang-disposition" attribute o Contact Name. XXXXXXXXXXXXXXXXXXXXXXXXXXXX o Contact Email Address. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX o Attribute Name: humintlang-disposition o Attribute Syntax: humintlang-disposition = "a=humintlang-disposition" HCOLON disposition o Attribute Semantics: If no match is possible, the value of the "humintlang-disposition" session level attribute should be interrogated by the answering party for the decision about how to handle the call. If the value is "reject", then the call MAY be rejected. There may however be application reasons to connect the call anyway. In that case the the humintlang-send actually intended to be used and the humintlang-recv value of the most likely combination to be initially used in the call shoud be included in the answer. Emergency calls should not be rejected because of language mismatch reasons. If the value of the "humintlang-disposition" session level attribute is "improve", then the party who inserted that value has some means to improve the match e.g. by adding an interpreting agent, e.g. a relay service. An answering party detecting the "improve" value may then connect the call, insert all its non-matching humintlang-send and humintlang-recv values and look forward to receiving new sdp with possibly better match. The offering party, or a service provider along the call path, detecting in the answer that the media/modality/direction/language indications did not match, may act to improve the match, e.g. by adding an interpreting agent, e.g. a relay service, to arrange for a better match. The parties involved in the call shall be informed about the result of such actions by new sdp with new values in the humintlang attributes. The mechanisms for such detection, decision and modifications of the call are out of scope for this specification. The ability to use such mechanisms shall be indicated by the value "improve" in the "humintlang-disposition" session attribute. When the value of the "humintlang-disposition" is "connect" (that is also the default value), then the call should be connected even without matching language/modality/direction indications. In that case the the humintlang-send actually intended to be used and the humintlang-recv value of the most likely combination to be initially used in the call shoud be included in the answer. The connected parties may use in-band actions to figure out if they have any human language communication means that fulfil the intentions of the call. o Attribute Value: disposition = "reject"/"complete"/"improve"/disposition-extension disposition-extension = token The value "complete" is default. o Usage Level: session o Charset Dependent: No. o Purpose: The attribute specifies how to handle the call when no language or modality match is found. o O/A Procedures: If no match is possible, the value of the "humintlang-disposition" session level attribute should be interrogated by the answering party for the decision about how to handle the call. If the value is "reject", then the call MAY be rejected. There may however be application reasons to connect the call anyway. In that case the the humintlang-send actually intended to be used and the humintlang-recv value of the most likely combination to be initially used in the call shoud be included in the answer. Emergency calls should not be rejected because of language mismatch reasons. An answering party detecting the "improve" value may then connect the call, insert all its non-matching humintlang-send and humintlang-recv values and look forward to receiving new sdp with possibly better match. The offering party, or a service provider along the call path, detecting in the answer that the media/modality/direction/language indications did not match, may act to improve the match, e.g. by adding an interpreting agent, e.g. a relay service, to arrange for a better match. The parties involved in the call shall be informed about the result of such actions by new sdp with new values in the humintlang attributes. When the value of the "humintlang-disposition" is "connect" (that is also the default value), then the call should be connected even without matching language/modality/direction indications. In that case the the humintlang-send actually intended to be used and the humintlang-recv value of the most likely combination to be initially used in the call shoud be included in the answer. o Mux Category: NORMAL o Reference: draft-ietf-slim-human-language-negotiation o Example: See the example for the humintlang-send and humintlang-recv attributes. Y. Specification of the humintlang-send and humintlang-recv attributes o Contact Name. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX o Contact Email Address. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX o Attribute Name: humintlang-recv humintlang-send o Attribute Syntax: humintlang-send = "a=humintlang-send" HCOLON [humintlang-value] humintlang-recv = "a=humintlang-recv" HCOLON [humintlang-value] When used without language parameter, the humintlang-send and humntlang-recv attribute indicates modality and direction for use with the default language of the area and media or media/subprotocol. o Attribute Semantics: In order to successfully start a call, the parties need to be aware of which language capabilities were negotiated, and also which modality the parties prefer to use. A call can start without hesitation and be conducted smoothly only when answered with the modality and language that best matches the most favoured combinations by the caller. There is a tendency among call participants to continue using the modality first used in a call, even if that is not the most favoured modality. The call participants usually want to communicate about the topic of the call, and not about how the call will be performed. Therefore, a mechanism is provided for indication of most preferred modality/modalities of the call participants together with the language attributes. The humintlang-send attribute indicates modality and language preferences for transmission from the indicating party. The humintlang-recv attribute indicates modality and language preferences for reception by the indicating party. The mechanism provides a "favoured" modality parameter that MAY be included in the "humintlang-send" and "humintlang-recv" attribute values on media level. The "favoured" modality parameter is a keyword parameter with the name "favoured" and values "most" and "complement". The "favoured" parameter is intended to be optionally included once for each combination of media, modality and direction of language. The indication is intended to carry the information that the indicated combination is the highest favoured alternative if the value is "most", and is a highly favoured complement to the most favoured modality in another media description if the value is "complement". The value "most" is allowed for more than one media/modality/direction combination for cases when it is essential for the indicating party to use more than one modality in the same direction. The "complement" value SHOULD not be used without any "most" value in the sdp, and should only be used for cases when the modality it is used with is supposed to be used for language transfer simultanously with the corresponding most favoured modality. The language parameter is an optional list of languages that the indicating party is prepared to use in the indicated media, modality and direction. The list is a whitespace separated list of language tags arranged in preference order, with highest preferred first. o Attribute Value: humintlang-value =[*humintlang-param][*language] humintlang-param = [modality][favoured] modality = "modality=" ("spoken"/"signed"/"written"/modality- extension) The value "spoken" is default for audio media. The value "signed" is default for video media except when used with a spoken or written language. The value "spoken" is default for video media when used with spoken language. The value "written" is default for text media favoured= "favoured="("most"/"complement") modality-extension = token Modalities can be extended with further modalities and assigned values indicated language = Language-Tag where Language-Tag is defined in RFC 5646, Section 2.1. o Usage Level: media, dcsa(subprotocol). dcsa(T140) can be indicated to carry text modality. o Charset Dependent: No o Purpose: In order to successfully start a call, the parties need to be aware of which language capabilities were negotiated, and also which modality the parties prefer to use. A call can start without hesitation and be conducted smoothly only when answered with the modality and language that best matches the most favoured combinations by the caller. The attributes are intended to carry the information about supported and favoured languages and modalities between the communicating parties. o O/A Procedures: Offering parties who strongly favour specific ways to communicate by language are expected to indicate these ways using the humintlang-send or humintlang-recv attributes with the "favoured=most" parameter on the most favoured media/modality/direction combination(s). A "favoured=most" indication may be included for all media/modality/direction combinations that are eagerly wanted together (usually one or two per direction). If one media/modality/direction is wanted together with a most favoured combination but with lower urgency, then the "favoured=complement" should be indicated (usually none or one per direction). Other media/modality/direction combinations SHALL be left without the "favoured" indication. When only one language indication for a direction in the whole sdp is indicated, it is regarded to be the most favoured language for the indicated direction. The answering party is expected to try to start the call in the media/modality/direction combinations indicated with favoured parameters in the languages highest preferred by the offering party. What the answering party does if no match is possible for the highest favoured combinations, or if no combinations are marked as highest favoured is application dependent, and depending on the "humintlang-disposition" session level attribute. Answering parties may select other than the highest favoured combinations of the offer or add an interpreting agent, e.g. a relay service to arrange for a better match in languages and modalities in the call. The media/modalities/directions/languages selected for language communication by the answering party shall be indicated by "humintlang-send" and "humintlang-recv" attributes in the answer. If no match is possible, the value of the "humintlang-disposition" session level attribute should be interrogated by the answering party for the decision about how to handle the call. If the value is "reject", then the call MAY be rejected. There may however be application reasons to connect the call anyway. In that case the the humintlang-send actually intended to be used and the humintlang-recv value of the most likely combination to be initially used in the call shoud be included in the answer. Emergency calls should not be rejected because of language mismatch reasons. The mechanism provides a "favoured" modality parameter that MAY be included in the "humintlang-send" and "humintlang-recv" attribute values on media level. The "favoured" modality parameter is a keyword parameter with the name "favoured" and values "most" and "complement". This parameter is intended to be optionally included once for each combination of media, modality and direction of language. The indication is intended to carry the information that the indicated combination is the highest favoured alternative if the value is "most", and is a highly favoured complement to the most favoured modality in another media description if the value is "complement". The value "most" is allowed for more than one media/modality/direction combination for cases when it is essential for the indicating party to use more than one modality in the same direction. The "complement" value SHOULD not be used without any "most" value in the sdp, and should only be used for cases when the modality it is used with is supposed to be used for language transfer simultanously with the corresponding most favoured modality. The offering party is expected to include all supported languages in the offer. The answering party who can match sufficient languages/modalities and directions of the offering party, is expected to include in the answer the languages selected for initial use in the call and include the "favoured=most" parameter for the modalities that the call is intended to start with. If no match was found, then all supported languages should be included and the "favoured=most" parameter for the modalities that the call is intended to start with. o Mux Category: NORMAL o Reference: draft-ietf-slim-human-language-negotiation o Examples: (with shortened surrounding sdp) Offer: s=- a=humintlang-disposition: connect m=audio 34056 RTP/AVP 8 a=humintlang-send: modality=spoken favoured=most en fr m=video 36068 RTP/AVP 34 m=text 35072 RTP/AVP 102 a=humintlang-recv: modality=written favoured=most en fr a=humintlang-send: modality=written en fr Answer s=- a=humintlang-disposition: connect m=audio 34066 RTP/AVP 8 a=humintlang-recv: modality=spoken favoured=most en m=video 0 RTP/AVP 34 m=text 35092 RTP/AVP 102 a=humintlang-send: modality=written favoured=most en This sdp exchange indicates that the offering party wants the call to be connected regardless of the outcome of the negotiation, and that the most favoured modality and language is to speak English, but speaking French is also possible. The offering party also offers video, but with no intention to use it for language. The incoming language is preferred in written real-time text form. The offering party can accept to send English or French text if the other party is not capable of receiving spoken English. The answering party accepts to connect the call, and use the favoured modalities in English. No video capability is available, so the video offer is rejected, but the call connected, and the answering party can start with a written text greeting and expect to get spoken response. Note: Both the humintlang-disposition value "connect" and the modalities indicated are the default values, so they could in this case have been left out with the same result. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Keywords: Attribute Severity: - | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Tue Aug 9 06:01:39 2016 Return-Path: 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 58B5912D81A for ; Tue, 9 Aug 2016 06:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 rtCTTTkqppYM for ; Tue, 9 Aug 2016 06:01:34 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B9F12D7E7 for ; Tue, 9 Aug 2016 06:01:34 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id l2so11229906qkf.3 for ; Tue, 09 Aug 2016 06:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5FfcjGY1FXOjaEyl8yMAK9KMxLEFl/yNyt6laspG9Mg=; b=qYuYFg7xMjBg9FkXOXiPNLqgWD9245JQYKdAuRVRtVKUQziLutjMXbcpokSNbBDigl X3t0hg0ehGHV0UZAHNKDSKWUMKf107EKMriFHREl0+3ezqmY+oFOnlW5sEl7ZwtjkPRX dpu/lDGoUPWX6DzRTqzhfHYLbqqKT9baneMx34vggTM4aTzTiX0Iid0WKXPej35GzvZf k4D26rNFi7MtdyGTxQ9aIU63Wj7zcKhC9Jx5+nBkhjmfTOj7QYb1PLAoz/9M7nb8fcIw qguZHokXingeHnlVTArgm7a18n8S1QPBK+14eeaKTf+Mel3JvBWofPOnDK2CZNr3LYjS ADFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5FfcjGY1FXOjaEyl8yMAK9KMxLEFl/yNyt6laspG9Mg=; b=LR9D17UWU3F1sYAD6CXQWV8WKZqVsek+Xm5qfhOKemc/UafHLQkXV0TJy7ODQo/VE9 8nYs1vCi8eVJp5TTXpAIiypP7mthFGFhmhBG4WJIf6m5+5zMyb/MGL1gC1uvzQlE4mPG ZUidlmV0MfI8Qh/WVFiZylJfaGTjcm0bCz15+iJauFS0uuPD7CBsYIIArWTZf/MWOfCi o0IpVAMhqmkmkIcrlfp75DzO+4FXBhXUtkpPaxZRwW0JGEDRYLq97UC9cU6RDWRNNeoF qf0R0AWk1NH71uRcex6uUMB1TpHH33uMobpn/oerkAvxDkGj54yo/AF8dfrUVi9oKDZk iDGg== X-Gm-Message-State: AEkoouujloonhf+SuFCyMUY4CN8xoUJGhXTA2r2tXrKhHjb79cMymdmFqD8cKNGy6z3NFA== X-Received: by 10.55.8.200 with SMTP id 191mr33635221qki.196.1470747693546; Tue, 09 Aug 2016 06:01:33 -0700 (PDT) Received: from [10.33.192.77] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r5sm20278074qkf.34.2016.08.09.06.01.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Aug 2016 06:01:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <082.6cbababa93e825f163e92644f6e9d826@tools.ietf.org> Date: Tue, 9 Aug 2016 09:01:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.6cbababa93e825f163e92644f6e9d826@tools.ietf.org> To: slim issue tracker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 13:01:38 -0000 I am not in favor of this change. I think the existing text is fine. Brian > On Aug 9, 2016, at 2:50 AM, slim issue tracker = wrote: >=20 > #7: The notation for Advisory vs Required is not logical and needs = revision >=20 >=20 > Comment (by gunnar.hellstrom@omnitor.se): >=20 > Modify the text in change 1 to: >=20 > The mechanism for indicating this preference is a session level = attribute > "humintlang-disposition", with "reject", "improve" and "connect" as > possible values and "connect" as default. >=20 > Example: > a=3Dhumintlang-disposition: reject >=20 > The called party MAY ignore the "reject" value, e.g., for the = emergency > services use case, a PSAP will likely not fail the call. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-slim- > gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: negotiating-human- | Version: > language | Resolution: > Severity: In WG Last Call | > Keywords: reject | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: = > slim >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Tue Aug 9 06:02:26 2016 Return-Path: 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 14A9612D801 for ; Tue, 9 Aug 2016 06:02:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 Oe7qhwuOcCrE for ; Tue, 9 Aug 2016 06:02:22 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7AE12D75A for ; Tue, 9 Aug 2016 06:02:22 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p186so11298949qkd.1 for ; Tue, 09 Aug 2016 06:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CzAuj/+etLr1DbpOQp4hR4pSXgo72zdsYGVoxB9tgcg=; b=WNTdS2zzWZwjZ7aGF+kUnLQTfR0UM/cH1Pw4H3frMfXfytlTRu4tdFzrvfG4av9MBH c7XEXUnqYkRvSpbxVzHHIj0emUCvw0NjilqkO24/MwN1XbKext98zKqrzzUdmW9uKO5M PpUQBMfI4yHrIkNBokArSNRvdtPAcfStjjR6DvJJ1QJFypM+yYQazYVxMamVx9wPj8of DaBJ0TMSapOCN8733KWCQ72KJVk0/Uo6eM/A6HD0JfpWPDPiptBhmyBo2MyeUrKg6Qpk MTPaS9k2KEw1EyK7tufMKhsIbr8oI/5ct8HWLAIipJyDAcI4uH9HjHe9q/1LUmN0UdTj GdZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CzAuj/+etLr1DbpOQp4hR4pSXgo72zdsYGVoxB9tgcg=; b=MMvyZDEQVjQqqO/IcGl0qhieqt+CRA9KIEfHIl+h79f4WIhpo8GajhBNrnuLZu3yU0 IEQ4LqXxIum1JvXbVD59G+74zkiKmIW6vWt4tq4MrRWdSAVUSjdF2kpNYTQJwpmS4LSt qgnsG9ytJtAmf0Inj/03e3jdG2rL7ABlA0GbxqBqwG2x+N1q3zM4/W4zfFKSDGI8aJdd C4vopGOteUVTBLHRpYVizYYqj93wNgq49O7Lne9twgj6bF3rm8weuGtveF8DlqAUE0nj oMJRvnIk96uNYu6LvfJWQ6Z5ZVSCeSAPqxVGd8tR6Gk1cjerCWJyGNey8v6IZYNew8ax oNcg== X-Gm-Message-State: AEkooutFc/1+yQ08mk3nWXYnj8uOfQesJYAnMXZlfdCvQrV//g/sDs5EDqJs3LnlBvq6cA== X-Received: by 10.55.165.138 with SMTP id o132mr33707927qke.90.1470747741405; Tue, 09 Aug 2016 06:02:21 -0700 (PDT) Received: from [10.33.192.77] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r5sm20278074qkf.34.2016.08.09.06.02.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Aug 2016 06:02:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> Date: Tue, 9 Aug 2016 09:02:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8480E1B1-019E-455C-A6EC-0AB73DE8E5B1@brianrosen.net> References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> To: slim issue tracker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, gunnar.hellstrom@omnitor.se, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 13:02:25 -0000 I don=E2=80=99t think this is a good idea. Brian > On Aug 9, 2016, at 3:03 AM, slim issue tracker = wrote: >=20 > #8: Introduce a section on most favoured modality >=20 > In order to have an opportunity to start the call in the most suitable > modality, an indication of most favoured modality is needed together = with > the language indications. Introduce a new section on that topic. = Without > this, the answering part is left without a clue about how to start the > call. >=20 > Text for new section in chapter 6 > ----------------------------------------------------------------- >=20 > 6.y Most favoured modality > In order to successfully start a call, the parties need to be aware of > which language capabilities were negotiated, and also which modality = the > parties prefer to use. A call can start without hesitation and be > conducted smoothly only when answered with the modality and language = that > best matches the most favoured combinations by the caller. There is a > tendency among call participants to continue using the modality first = used > in a call, even if that is not the most favoured modality. The call > participants usually want to communicate about the topic of the call, = and > not about how the call will be performed. Therefore, a mechanism is > provided for indication of most preferred modality/modalities of the = call > participants together with the language attributes. >=20 > The mechanism provides a "favoured" modality parameter that MAY be > included in the "humintlang-send" and "humintlang-recv" attribute = values > on media level. The "favoured" modality parameter is a keyword = parameter > with the name "favoured" and values "most" and "complement". > This parameter is intended to be optionally included once for each > combination of media, modality and direction of language. The = indication > is intended to carry the information that that combination is the = highest > favoured alternative if the value is "most", and is a highly favoured > complement to the most favoured modality in another media description = if > the value is "complement". The value "most" is allowed for more than = one > media/modality/direction combination for cases when it is essential = for > the indicating party to use more than one modality in the same = direction. > The "complement" value SHOULD not be used without any "most" value in = the > sdp, and should only be used for cases when the modality it is used = with > is supposed to be used for language transfer simultanously with the > corresponding most favoured modality. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-slim- > gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: negotiating-human- | Version: > language | Keywords: modality > Severity: In WG Last Call | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > slim >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Tue Aug 9 06:06:58 2016 Return-Path: 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 ED61D12D804 for ; Tue, 9 Aug 2016 06:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 xbUtJKp_yxkG for ; Tue, 9 Aug 2016 06:06:55 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD02812D801 for ; Tue, 9 Aug 2016 06:06:54 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id t7so11512955qkh.0 for ; Tue, 09 Aug 2016 06:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ru7SZ6D3kcdi47s6/T7qH7HiVOxFs9+LgMiqcldyvkM=; b=TwrLNk7p9yYrfZs3/c1fqvkNneOKb87uCtfQAotjktgzByV/8P65Oa1sPAzlHBRjm7 dtThJjWangovVmoBgBk1AUbES3fD448HPQkvKkGXbz6uKi34GZp0eZUlmS1wSbfxM0GG ASChaIsaMq957OsVod7OtbdCUZBfYMxHakYWJqPBRUEzVLLl95rCwfRNj9157UTuq0gN e0r/VSCzr3I9knfGajAkigOk35MkLXDwGY4fZY27qY4c0BkANW6q0ni3DZHlVTVeytEz vBtJicvC7Gp8MRGGzbMCDY/dvMZMZMOL+OYbWn1ajFN/AHtenAT4mqUXmI4HPM3mopFk 2XZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ru7SZ6D3kcdi47s6/T7qH7HiVOxFs9+LgMiqcldyvkM=; b=Q47937UAqYx82Gro8+3KQU661m7Han+PFQhJx37SC/9H5MG2isr4P8nvHKlaHzBLwQ zuSTjwJJ5Ci3ZmJUzlGhJM48VjDqUJooKlU/C5DsGJXvxQwnhexoQrdv9kBomOjFXvLH AAtH3cfOdIrl8PB+apUERi6i0ggqUcleEeAnAfWxDq0kvTnfttF9M5NSlU6xeCdmOAbA i3YUwSfp2g96bD8TnqNm5EKutpLzkyBz+/AacuR/FiZTCnmuLiC/wcGFV0m7Eh8XQ3X4 9Xz+0O1+CdewjtBS/MK5s2gExzDkVq413CwDm2Lr+0SpAc53vCgCswzenyjRuSjcUJvA lXRA== X-Gm-Message-State: AEkoout7pW0uOHvsg8xhP5VX5twSMS4YZkWIRwjYklS3kJWNPudoHYtMRrXtVa8Fy2s4gg== X-Received: by 10.55.16.218 with SMTP id 87mr36391517qkq.220.1470748013479; Tue, 09 Aug 2016 06:06:53 -0700 (PDT) Received: from [10.33.192.77] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r5sm20290225qkf.34.2016.08.09.06.06.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Aug 2016 06:06:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> Date: Tue, 9 Aug 2016 09:06:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> To: slim issue tracker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, gunnar.hellstrom@omnitor.se, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 13:06:57 -0000 I agree that we need to conform to the 4566 template. I don=E2=80=99t agree with changing the definition of the attribute. Brian > On Aug 9, 2016, at 4:49 AM, slim issue tracker = wrote: >=20 > #9: Attribute specifications following the layout required by = RFC4566bis >=20 > The attribute specifications need to be more formal than in the = current > draft (-04 ) >=20 > The following is required from attribute specifications according to = RFC > 4566bis, section 8.2.4.1: >=20 >=20 >=20 > "New attribute registrations are accepted according to the > "Specification Required" policy of [RFC5226], provided that the > specification includes the following information: >=20 > o Contact Name. >=20 > o Contact Email Address. >=20 > o Attribute Name: The name of the attribute that will appear in > SDP). This MUST conform to the definition of . >=20 > o Attribute Syntax: For a value attribute (see clause 5.13), an = ABNF > definition of the attribute value syntax (See > Section Section 9) MUST be provided. The syntax MUST follow the > rule form as per Section 2.2 of [RFC5234]. This SHALL define = the > allowable values that the attribute might take. It MAY also > define an extension method for the addition of future values. = For > a property attribute, the ABNF definition is omitted as the > property attribute takes no values. >=20 > o Attribute Semantics: For a value attribute, a semantic = description > of the values that the attribute might take MUST be provided. = The > usage of a property attribute is described under purpose below. >=20 > o Attribute Value: The name of an ABNF syntax rule defining the > syntax of the value. Absence of a rule name indicates that the > attribute takes no values. Enclosing the rule name in "[" and = "]" > indicates that a value is optional. >=20 > o Usage Level: Usage level(s) of the attribute. One or more of: > session, media, source, dcsa, dcsa(subprotocol). For a = definition > of source level attributes, see [RFC5576]. For a definition of > dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. >=20 > o Charset Dependent: Whether the attribute value is subject to the > charset attribute or not (Yes/No). >=20 > o Purpose: An explanation of the purpose and usage of the = attribute. >=20 > o O/A Procedures: Offer/Answer procedures as explained in = [RFC3264]. >=20 > o Mux Category: Indication of which multiplexing "category" > [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated > with. >=20 > o Reference: A reference to the specification defining the > attribute. > " >=20 >=20 > --------------------------------------------------------------- > Change. Add chapters on the attributes in the format described in > RFC4566bis, section 8.2.4.1 >=20 > Some changes are also needed in the earlier text in the draft to align > with these attribute specifications. > -------------------------------------------------------------------- >=20 >=20 > x. Specification of the "humintlang-disposition" attribute >=20 > o Contact Name. > XXXXXXXXXXXXXXXXXXXXXXXXXXXX >=20 > o Contact Email Address. > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >=20 > o Attribute Name: > humintlang-disposition >=20 > o Attribute Syntax: > humintlang-disposition =3D "a=3Dhumintlang-disposition" HCOLON = disposition >=20 > o Attribute Semantics: > If no match is possible, the value of the "humintlang-disposition" > session level attribute should be interrogated by the answering party = for > the decision about how to handle the call. If the value is "reject", = then > the call MAY be rejected. There may however be application reasons to > connect the call anyway. In that case the the humintlang-send actually > intended to be used and the humintlang-recv value of the most likely > combination to be initially used in the call shoud be included in the > answer. Emergency calls should not be rejected because of language > mismatch reasons. >=20 > If the value of the "humintlang-disposition" session level > attribute is "improve", then the party who inserted that value has = some > means to improve the match e.g. by adding an interpreting agent, e.g. = a > relay service. An answering party detecting the "improve" value may = then > connect the call, insert all its non-matching humintlang-send and > humintlang-recv values and look forward to receiving new sdp with = possibly > better match. The offering party, or a service provider along the call > path, detecting in the answer that the = media/modality/direction/language > indications did not match, may act to improve the match, e.g. by = adding an > interpreting agent, e.g. a relay service, to arrange for a better = match. > The parties involved in the call shall be informed about the result of > such actions by new sdp with new values in the humintlang attributes. = The > mechanisms for such detection, decision and modifications of the call = are > out of scope for this specification. The ability to use such = mechanisms > shall be indicated by the value "improve" in the = "humintlang-disposition" > session attribute. >=20 > When the value of the "humintlang-disposition" is "connect" = (that > is also the default value), then the call should be connected even = without > matching language/modality/direction indications. In that case the the > humintlang-send actually intended to be used and the humintlang-recv = value > of the most likely combination to be initially used in the call shoud = be > included in the answer. The connected parties may use in-band actions = to > figure out if they have any human language communication means that = fulfil > the intentions of the call. >=20 > o Attribute Value: > disposition =3D "reject"/"complete"/"improve"/disposition-extension > disposition-extension =3D token > The value "complete" is default. >=20 > o Usage Level: > session >=20 > o Charset Dependent: No. >=20 > o Purpose: > The attribute specifies how to handle the call when no language or > modality match is found. >=20 >=20 > o O/A Procedures: > If no match is possible, the value of the = "humintlang-disposition" > session level attribute should be interrogated by the answering party = for > the decision about how to handle the call. If the value is "reject", = then > the call MAY be rejected. There may however be application reasons to > connect the call anyway. In that case the the humintlang-send actually > intended to be used and the humintlang-recv value of the most likely > combination to be initially used in the call shoud be included in the > answer. Emergency calls should not be rejected because of language > mismatch reasons. >=20 > An answering party detecting the "improve" value may then = connect > the call, insert all its non-matching humintlang-send and = humintlang-recv > values and look forward to receiving new sdp with possibly better = match. > The offering party, or a service provider along the call path, = detecting > in the answer that the media/modality/direction/language indications = did > not match, may act to improve the match, e.g. by adding an = interpreting > agent, e.g. a relay service, to arrange for a better match. The = parties > involved in the call shall be informed about the result of such = actions by > new sdp with new values in the humintlang attributes. >=20 > When the value of the "humintlang-disposition" is "connect" = (that > is also the default value), then the call should be connected even = without > matching language/modality/direction indications. In that case the the > humintlang-send actually intended to be used and the humintlang-recv = value > of the most likely combination to be initially used in the call shoud = be > included in the answer. >=20 > o Mux Category: > NORMAL >=20 > o Reference: >=20 > draft-ietf-slim-human-language-negotiation >=20 > o Example: > See the example for the humintlang-send and humintlang-recv = attributes. >=20 >=20 >=20 > Y. Specification of the humintlang-send and humintlang-recv attributes >=20 > o Contact Name. > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >=20 > o Contact Email Address. > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >=20 > o Attribute Name: > humintlang-recv >=20 > humintlang-send >=20 >=20 >=20 > o Attribute Syntax: > humintlang-send =3D "a=3Dhumintlang-send" HCOLON = [humintlang-value] >=20 > humintlang-recv =3D "a=3Dhumintlang-recv" HCOLON = [humintlang-value] >=20 > When used without language parameter, the humintlang-send and > humntlang-recv attribute indicates modality and direction for use with = the > default language of the area and media or media/subprotocol. >=20 >=20 > o Attribute Semantics: > In order to successfully start a call, the parties need to be aware = of > which language capabilities were negotiated, and also which modality = the > parties prefer to use. A call can start without hesitation and be > conducted smoothly only when answered with the modality and language = that > best matches the most favoured combinations by the caller. There is a > tendency among call participants to continue using the modality first = used > in a call, even if that is not the most favoured modality. The call > participants usually want to communicate about the topic of the call, = and > not about how the call will be performed. Therefore, a mechanism is > provided for indication of most preferred modality/modalities of the = call > participants together with the language attributes. >=20 > The humintlang-send attribute indicates modality and language > preferences for transmission from the indicating party. > The humintlang-recv attribute indicates modality and language > preferences for reception by the indicating party. >=20 > The mechanism provides a "favoured" modality parameter that = MAY be > included in the "humintlang-send" and "humintlang-recv" attribute = values > on media level. The "favoured" modality parameter is a keyword = parameter > with the name "favoured" and values "most" and "complement". >=20 > The "favoured" parameter is intended to be optionally included > once for each combination of media, modality and direction of = language. > The indication is intended to carry the information that the indicated > combination is the highest favoured alternative if the value is = "most", > and is a highly favoured complement to the most favoured modality in > another media description if the value is "complement". The value = "most" > is allowed for more than one media/modality/direction combination for > cases when it is essential for the indicating party to use more than = one > modality in the same direction. The "complement" value SHOULD not be = used > without any "most" value in the sdp, and should only be used for cases > when the modality it is used with is supposed to be used for language > transfer simultanously with the corresponding most favoured modality. >=20 > The language parameter is an optional list of languages that = the > indicating party is prepared to use in the indicated media, modality = and > direction. The list is a whitespace separated list of language tags > arranged in preference order, with highest preferred first. >=20 >=20 > o Attribute Value: >=20 > humintlang-value =3D[*humintlang-param][*language] > humintlang-param =3D [modality][favoured] > modality =3D "modality=3D" = ("spoken"/"signed"/"written"/modality- > extension) > The value "spoken" is default for audio media. > The value "signed" is default for video media except when used > with a spoken or written language. > The value "spoken" is default for video media when used with > spoken language. > The value "written" is default for text media > favoured=3D "favoured=3D"("most"/"complement") > modality-extension =3D token > Modalities can be extended with further modalities and = assigned > values indicated > language =3D Language-Tag > where Language-Tag is defined in RFC 5646, Section 2.1. >=20 >=20 > o Usage Level: > media, dcsa(subprotocol). > dcsa(T140) can be indicated to carry text modality. >=20 > o Charset Dependent: No >=20 > o Purpose: > In order to successfully start a call, the parties need to be = aware of > which language capabilities were negotiated, and also which modality = the > parties prefer to use. A call can start without hesitation and be > conducted smoothly only when answered with the modality and language = that > best matches the most favoured combinations by the caller. The = attributes > are intended to carry the information about supported and favoured > languages and modalities between the communicating parties. >=20 > o O/A Procedures: > Offering parties who strongly favour specific ways to = communicate > by language are expected to indicate these ways using the = humintlang-send > or humintlang-recv attributes with the "favoured=3Dmost" parameter on = the > most favoured media/modality/direction combination(s). A = "favoured=3Dmost" > indication may be included for all media/modality/direction = combinations > that are eagerly wanted together (usually one or two per direction). = If > one media/modality/direction is wanted together with a most favoured > combination but with lower urgency, then the "favoured=3Dcomplement" = should > be indicated (usually none or one per direction). Other > media/modality/direction combinations SHALL be left without the = "favoured" > indication. >=20 > When only one language indication for a direction in the whole = sdp > is indicated, it is regarded to be the most favoured language for the > indicated direction. >=20 > The answering party is expected to try to start the call in = the > media/modality/direction combinations indicated with favoured = parameters > in the languages highest preferred by the offering party. What the > answering party does if no match is possible for the highest favoured > combinations, or if no combinations are marked as highest favoured is > application dependent, and depending on the "humintlang-disposition" > session level attribute. Answering parties may select other than the > highest favoured combinations of the offer or add an interpreting = agent, > e.g. a relay service to arrange for a better match in languages and > modalities in the call. The media/modalities/directions/languages = selected > for language communication by the answering party shall be indicated = by > "humintlang-send" and "humintlang-recv" attributes in the answer. If = no > match is possible, the value of the "humintlang-disposition" session = level > attribute should be interrogated by the answering party for the = decision > about how to handle the call. If the value is "reject", then the call = MAY > be rejected. There may however be application reasons to connect the = call > anyway. In that case the the humintlang-send actually intended to be = used > and the humintlang-recv value of the most likely combination to be > initially used in the call shoud be included in the answer. Emergency > calls should not be rejected because of language mismatch reasons. = The > mechanism provides a "favoured" modality parameter that MAY be = included in > the "humintlang-send" and "humintlang-recv" attribute values on media > level. The "favoured" modality parameter is a keyword parameter with = the > name "favoured" and values "most" and "complement". >=20 > This parameter is intended to be optionally included once for = each > combination of media, modality and direction of language. The = indication > is intended to carry the information that the indicated = combination is > the highest favoured alternative if the value is "most", and is a = highly > favoured complement to the most favoured modality in another media > description if the value is "complement". The value "most" is allowed = for > more than one media/modality/direction combination for cases when it = is > essential for the indicating party to use more than one modality in = the > same direction. The "complement" value SHOULD not be used without any > "most" value in the sdp, and should only be used for cases when the > modality it is used with is supposed to be used for language transfer > simultanously with the corresponding most favoured modality. >=20 > The offering party is expected to include all supported = languages > in the offer. The answering party who can match sufficient > languages/modalities and directions of the offering party, is expected = to > include in the answer the languages selected for initial use in the = call > and include the "favoured=3Dmost" parameter for the modalities that = the call > is intended to start with. If no match was found, then all supported > languages should be included and the "favoured=3Dmost" parameter for = the > modalities that the call is intended to start with. >=20 > o Mux Category: > NORMAL >=20 > o Reference: > draft-ietf-slim-human-language-negotiation >=20 > o Examples: (with shortened surrounding sdp) >=20 > Offer: > s=3D- > a=3Dhumintlang-disposition: connect > m=3Daudio 34056 RTP/AVP 8 > a=3Dhumintlang-send: modality=3Dspoken favoured=3Dmost en fr > m=3Dvideo 36068 RTP/AVP 34 > m=3Dtext 35072 RTP/AVP 102 > a=3Dhumintlang-recv: modality=3Dwritten favoured=3Dmost en fr > a=3Dhumintlang-send: modality=3Dwritten en fr >=20 > Answer > s=3D- > a=3Dhumintlang-disposition: connect > m=3Daudio 34066 RTP/AVP 8 > a=3Dhumintlang-recv: modality=3Dspoken favoured=3Dmost en > m=3Dvideo 0 RTP/AVP 34 > m=3Dtext 35092 RTP/AVP 102 > a=3Dhumintlang-send: modality=3Dwritten favoured=3Dmost en >=20 >=20 > This sdp exchange indicates that the offering party wants the call to = be > connected regardless of the outcome of the negotiation, and that the = most > favoured modality and language is to speak English, but speaking = French is > also possible. > The offering party also offers video, but with no intention to use it = for > language. > The incoming language is preferred in written real-time text form. > The offering party can accept to send English or French text if the = other > party is not capable of receiving spoken English. >=20 > The answering party accepts to connect the call, and use the favoured > modalities in English. No video capability is available, so the video > offer is rejected, but the call connected, and the answering party can > start with a written text greeting and expect to get spoken response. >=20 > Note: Both the humintlang-disposition value "connect" and the = modalities > indicated are the default values, so they could in this case have been > left out with the same result. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-slim- > gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: negotiating-human- | Version: > language | Keywords: Attribute > Severity: - | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > slim >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Wed Aug 10 11:53:33 2016 Return-Path: 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 8111512D658 for ; Wed, 10 Aug 2016 11:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zHqFLKMZSkMj for ; Wed, 10 Aug 2016 11:53:30 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9C812B042 for ; Wed, 10 Aug 2016 11:53:30 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 74so84857520uau.0 for ; Wed, 10 Aug 2016 11:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UI7SMBakOUzaRxazvbuZUAes3LNVsY1UDy3B9u/qngY=; b=dAwFGTjqp9kFowD89O0FNOYYlMf63e2UUZ1wImT8XZ2DC11LFNkGqjLyA2RQLb0Yyc ablpRcAgkK+Ueh7YRKUSXkcrxGUDKrXfFzXueeXUaKTVKsF3y15I4Qp+YDHiPxV+f3pp HaEinXAaua7CIe4e7z5OihKGGarrJ5T4YKK1Y3s9cAgwobJUtRBwYmqog3XkC5DDI36b /iEdsqqGzTSZ9n8TItJVseUU2gh62Cymci5S7k2RFGO8w9EQh2w/Bo/4iMWbiV8Us3ON bo8H92kd3jXYaj9WVUgsF5ukAb6PKtiIFJ5ypz/S/uW2svhYQf7QTVZtriP77VG+u1PR 81cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UI7SMBakOUzaRxazvbuZUAes3LNVsY1UDy3B9u/qngY=; b=a6O8jNSAghJQuuacOSt8X7AXJhIMRx6VSz3ifUDtUhJDd7rqxWMf6nGMVwVzhQJJRg mfIszQZcbyFZ8SwF62f8HI6IaqifsOoydtA154VnniXDy4x1it2lefGu3W616qZKuQfJ Rm1Mvod0x2ii9eXMCftXEL49OBAPioUxXXBfQL1NMJqxR97DhXtutyYszX2Ebl62LhUV sCJFACn4+Y4bgEIc1ay6qKcDeHQRkpSbq/N2ZQXwhfhHNg++QOrH6d59TUewtThYEisM koyDNuAEkDEgDcxuigTT1GX1HdZ6cimg6icWZgQtgCaan7EljS2ZHVip2zWWu186Efup ks1A== X-Gm-Message-State: AEkoousNkWfy2ouoCMcP1KBvNwx+nZRsFvd03J939wsOeB1e61GgKDT3eirRs6KNhptRLnVQrR2GmJVruWgByg== X-Received: by 10.176.3.242 with SMTP id 105mr2871316uau.112.1470855209607; Wed, 10 Aug 2016 11:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.184 with HTTP; Wed, 10 Aug 2016 11:53:09 -0700 (PDT) From: Bernard Aboba Date: Wed, 10 Aug 2016 11:53:09 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=94eb2c067ea848ea990539bc2a05 Archived-At: Subject: [Slim] Reminder: Documents in WG Last Call X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 18:53:32 -0000 --94eb2c067ea848ea990539bc2a05 Content-Type: text/plain; charset=UTF-8 This is a reminder that the following documents are in SLIM WG Last Call, ending on August 12: Multiple Language Content Type: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent Negotiating Human Language in Real-Time Communications https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language To submit issues on the documents, please use the IETF Issue Tracker: https://tools.ietf.org/wg/slim/trac/newticket As noted at IETF 96, it is the expectation of the WG Chairs that IPR declarations will be submitted by the end of WG last call on August 12, 2016. The IETF policy on late declarations and sanctions is described in RFC 6071 (https://tools.ietf.org/html/rfc6701) --94eb2c067ea848ea990539bc2a05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a reminder that the following documents are in SLI= M WG Last Call, ending on August 12:

Multiple Language C= ontent Type:

Negotiating Human Language in Real-Time= Communications

To submit issues= on the documents, please use the IETF Issue Tracker:=C2=A0


As n= oted at IETF 96, it is the expectation of the WG Chairs that IPR declaratio= ns will be submitted by the end of WG last call on August 12, 2016. =C2=A0<= /div>

The IETF policy on late declarations and sanctions= is described in RFC 6071 (= https://tools.ietf.org/html/rfc6701)
--94eb2c067ea848ea990539bc2a05-- From nobody Fri Aug 12 12:33:27 2016 Return-Path: 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 7535812DA88 for ; Fri, 12 Aug 2016 12:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 JmgTCvZSnCVO for ; Fri, 12 Aug 2016 12:33:22 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 D67E912D938 for ; Fri, 12 Aug 2016 12:33:21 -0700 (PDT) X-Halon-ID: 9cd32362-60c3-11e6-88cf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 12 Aug 2016 21:33:14 +0200 (CEST) To: Brian Rosen , slim issue tracker References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 12 Aug 2016 21:33:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 19:33:26 -0000 Den 2016-08-09 kl. 15:06, skrev Brian Rosen: > I agree that we need to conform to the 4566 template. > > I don’t agree with changing the definition of the attribute. I find it hard to see that you do not agree in any of the proposed changes in the definitions. Here they are in a numbered list. 1. Move the session level parameter about rejecting or connecting the call in case of no language match to session level. There is no logically correct place for this parameter in the media level attributes. 2. Revert the default value of the rejecting or connecting the call at no match to be connecting. That matches the scope of the parameter better, and is in line with the discussion in the mail list. 3. Add a value "improve" to the session level attribute, with the meaning "I can improve language matches by introduction of means not initially indicated. ( such as a caller not invoking a relay service initially, but after the answer when it shows that a relay service is needed. ) 4. Introduce a modality parameter in the humintlang-send and humintlang-recv attribute values. Default values handle most cases, but there are cases when an explicit value is needed, because it is not evident from the m-line and the language tag what modality indicated. This is especially true for m=application cases. (A complex alternative would be to specify all cases we know now explicitly of language use where it is not explicit by the mime type and the language tag what modality is intended, but I think that is too inflexible. ) 5. Combine all languages for one media, modality and direction in a space separated list as value to one humintlang-send or humintlang-recv attribute. That matches the format of the SIP Accept-Language field value. It also matches the logic of only indicating one highest favoured language. It would be possible to have only one language per humintlang-send or humintlang-recv attribute and include multiple attributes per media and direction. But then the syntax of the most favoured parameter gets less logical. Therefore I propose the changed attribute syntax. 6. Introduce a mark for most favoured media, meaning that the first language in the value list of the corresponding attribute is the most favoured for that direction. This can enable the negotiation to result in good decisions so that language exchange gets efficient. Without it, the start of the call will be in randomly selected modality and language among a set with undefined relative favour, causing problems to correct the modality and language when it gets initially wrong. 7. Allow indication of up to two highest favoured modalities per direction, or one highest favoured and one complementing, so that good decisions can be made. That enables specifying the needs behind the use of some common types of relay services or favoured behavior of the other party. Without this, there are calls that will not be answered in the most efficient way, instead causing confusion and delay. Regards Gunnar > > Brian > > > >> On Aug 9, 2016, at 4:49 AM, slim issue tracker wrote: >> >> #9: Attribute specifications following the layout required by RFC4566bis >> >> The attribute specifications need to be more formal than in the current >> draft (-04 ) >> >> The following is required from attribute specifications according to RFC >> 4566bis, section 8.2.4.1: >> >> >> >> "New attribute registrations are accepted according to the >> "Specification Required" policy of [RFC5226], provided that the >> specification includes the following information: >> >> o Contact Name. >> >> o Contact Email Address. >> >> o Attribute Name: The name of the attribute that will appear in >> SDP). This MUST conform to the definition of . >> >> o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF >> definition of the attribute value syntax (See >> Section Section 9) MUST be provided. The syntax MUST follow the >> rule form as per Section 2.2 of [RFC5234]. This SHALL define the >> allowable values that the attribute might take. It MAY also >> define an extension method for the addition of future values. For >> a property attribute, the ABNF definition is omitted as the >> property attribute takes no values. >> >> o Attribute Semantics: For a value attribute, a semantic description >> of the values that the attribute might take MUST be provided. The >> usage of a property attribute is described under purpose below. >> >> o Attribute Value: The name of an ABNF syntax rule defining the >> syntax of the value. Absence of a rule name indicates that the >> attribute takes no values. Enclosing the rule name in "[" and "]" >> indicates that a value is optional. >> >> o Usage Level: Usage level(s) of the attribute. One or more of: >> session, media, source, dcsa, dcsa(subprotocol). For a definition >> of source level attributes, see [RFC5576]. For a definition of >> dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. >> >> o Charset Dependent: Whether the attribute value is subject to the >> charset attribute or not (Yes/No). >> >> o Purpose: An explanation of the purpose and usage of the attribute. >> >> o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. >> >> o Mux Category: Indication of which multiplexing "category" >> [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated >> with. >> >> o Reference: A reference to the specification defining the >> attribute. >> " >> >> >> --------------------------------------------------------------- >> Change. Add chapters on the attributes in the format described in >> RFC4566bis, section 8.2.4.1 >> >> Some changes are also needed in the earlier text in the draft to align >> with these attribute specifications. >> -------------------------------------------------------------------- >> >> >> x. Specification of the "humintlang-disposition" attribute >> >> o Contact Name. >> XXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> o Contact Email Address. >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> o Attribute Name: >> humintlang-disposition >> >> o Attribute Syntax: >> humintlang-disposition = "a=humintlang-disposition" HCOLON disposition >> >> o Attribute Semantics: >> If no match is possible, the value of the "humintlang-disposition" >> session level attribute should be interrogated by the answering party for >> the decision about how to handle the call. If the value is "reject", then >> the call MAY be rejected. There may however be application reasons to >> connect the call anyway. In that case the the humintlang-send actually >> intended to be used and the humintlang-recv value of the most likely >> combination to be initially used in the call shoud be included in the >> answer. Emergency calls should not be rejected because of language >> mismatch reasons. >> >> If the value of the "humintlang-disposition" session level >> attribute is "improve", then the party who inserted that value has some >> means to improve the match e.g. by adding an interpreting agent, e.g. a >> relay service. An answering party detecting the "improve" value may then >> connect the call, insert all its non-matching humintlang-send and >> humintlang-recv values and look forward to receiving new sdp with possibly >> better match. The offering party, or a service provider along the call >> path, detecting in the answer that the media/modality/direction/language >> indications did not match, may act to improve the match, e.g. by adding an >> interpreting agent, e.g. a relay service, to arrange for a better match. >> The parties involved in the call shall be informed about the result of >> such actions by new sdp with new values in the humintlang attributes. The >> mechanisms for such detection, decision and modifications of the call are >> out of scope for this specification. The ability to use such mechanisms >> shall be indicated by the value "improve" in the "humintlang-disposition" >> session attribute. >> >> When the value of the "humintlang-disposition" is "connect" (that >> is also the default value), then the call should be connected even without >> matching language/modality/direction indications. In that case the the >> humintlang-send actually intended to be used and the humintlang-recv value >> of the most likely combination to be initially used in the call shoud be >> included in the answer. The connected parties may use in-band actions to >> figure out if they have any human language communication means that fulfil >> the intentions of the call. >> >> o Attribute Value: >> disposition = "reject"/"complete"/"improve"/disposition-extension >> disposition-extension = token >> The value "complete" is default. >> >> o Usage Level: >> session >> >> o Charset Dependent: No. >> >> o Purpose: >> The attribute specifies how to handle the call when no language or >> modality match is found. >> >> >> o O/A Procedures: >> If no match is possible, the value of the "humintlang-disposition" >> session level attribute should be interrogated by the answering party for >> the decision about how to handle the call. If the value is "reject", then >> the call MAY be rejected. There may however be application reasons to >> connect the call anyway. In that case the the humintlang-send actually >> intended to be used and the humintlang-recv value of the most likely >> combination to be initially used in the call shoud be included in the >> answer. Emergency calls should not be rejected because of language >> mismatch reasons. >> >> An answering party detecting the "improve" value may then connect >> the call, insert all its non-matching humintlang-send and humintlang-recv >> values and look forward to receiving new sdp with possibly better match. >> The offering party, or a service provider along the call path, detecting >> in the answer that the media/modality/direction/language indications did >> not match, may act to improve the match, e.g. by adding an interpreting >> agent, e.g. a relay service, to arrange for a better match. The parties >> involved in the call shall be informed about the result of such actions by >> new sdp with new values in the humintlang attributes. >> >> When the value of the "humintlang-disposition" is "connect" (that >> is also the default value), then the call should be connected even without >> matching language/modality/direction indications. In that case the the >> humintlang-send actually intended to be used and the humintlang-recv value >> of the most likely combination to be initially used in the call shoud be >> included in the answer. >> >> o Mux Category: >> NORMAL >> >> o Reference: >> >> draft-ietf-slim-human-language-negotiation >> >> o Example: >> See the example for the humintlang-send and humintlang-recv attributes. >> >> >> >> Y. Specification of the humintlang-send and humintlang-recv attributes >> >> o Contact Name. >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> o Contact Email Address. >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> o Attribute Name: >> humintlang-recv >> >> humintlang-send >> >> >> >> o Attribute Syntax: >> humintlang-send = "a=humintlang-send" HCOLON [humintlang-value] >> >> humintlang-recv = "a=humintlang-recv" HCOLON [humintlang-value] >> >> When used without language parameter, the humintlang-send and >> humntlang-recv attribute indicates modality and direction for use with the >> default language of the area and media or media/subprotocol. >> >> >> o Attribute Semantics: >> In order to successfully start a call, the parties need to be aware of >> which language capabilities were negotiated, and also which modality the >> parties prefer to use. A call can start without hesitation and be >> conducted smoothly only when answered with the modality and language that >> best matches the most favoured combinations by the caller. There is a >> tendency among call participants to continue using the modality first used >> in a call, even if that is not the most favoured modality. The call >> participants usually want to communicate about the topic of the call, and >> not about how the call will be performed. Therefore, a mechanism is >> provided for indication of most preferred modality/modalities of the call >> participants together with the language attributes. >> >> The humintlang-send attribute indicates modality and language >> preferences for transmission from the indicating party. >> The humintlang-recv attribute indicates modality and language >> preferences for reception by the indicating party. >> >> The mechanism provides a "favoured" modality parameter that MAY be >> included in the "humintlang-send" and "humintlang-recv" attribute values >> on media level. The "favoured" modality parameter is a keyword parameter >> with the name "favoured" and values "most" and "complement". >> >> The "favoured" parameter is intended to be optionally included >> once for each combination of media, modality and direction of language. >> The indication is intended to carry the information that the indicated >> combination is the highest favoured alternative if the value is "most", >> and is a highly favoured complement to the most favoured modality in >> another media description if the value is "complement". The value "most" >> is allowed for more than one media/modality/direction combination for >> cases when it is essential for the indicating party to use more than one >> modality in the same direction. The "complement" value SHOULD not be used >> without any "most" value in the sdp, and should only be used for cases >> when the modality it is used with is supposed to be used for language >> transfer simultanously with the corresponding most favoured modality. >> >> The language parameter is an optional list of languages that the >> indicating party is prepared to use in the indicated media, modality and >> direction. The list is a whitespace separated list of language tags >> arranged in preference order, with highest preferred first. >> >> >> o Attribute Value: >> >> humintlang-value =[*humintlang-param][*language] >> humintlang-param = [modality][favoured] >> modality = "modality=" ("spoken"/"signed"/"written"/modality- >> extension) >> The value "spoken" is default for audio media. >> The value "signed" is default for video media except when used >> with a spoken or written language. >> The value "spoken" is default for video media when used with >> spoken language. >> The value "written" is default for text media >> favoured= "favoured="("most"/"complement") >> modality-extension = token >> Modalities can be extended with further modalities and assigned >> values indicated >> language = Language-Tag >> where Language-Tag is defined in RFC 5646, Section 2.1. >> >> >> o Usage Level: >> media, dcsa(subprotocol). >> dcsa(T140) can be indicated to carry text modality. >> >> o Charset Dependent: No >> >> o Purpose: >> In order to successfully start a call, the parties need to be aware of >> which language capabilities were negotiated, and also which modality the >> parties prefer to use. A call can start without hesitation and be >> conducted smoothly only when answered with the modality and language that >> best matches the most favoured combinations by the caller. The attributes >> are intended to carry the information about supported and favoured >> languages and modalities between the communicating parties. >> >> o O/A Procedures: >> Offering parties who strongly favour specific ways to communicate >> by language are expected to indicate these ways using the humintlang-send >> or humintlang-recv attributes with the "favoured=most" parameter on the >> most favoured media/modality/direction combination(s). A "favoured=most" >> indication may be included for all media/modality/direction combinations >> that are eagerly wanted together (usually one or two per direction). If >> one media/modality/direction is wanted together with a most favoured >> combination but with lower urgency, then the "favoured=complement" should >> be indicated (usually none or one per direction). Other >> media/modality/direction combinations SHALL be left without the "favoured" >> indication. >> >> When only one language indication for a direction in the whole sdp >> is indicated, it is regarded to be the most favoured language for the >> indicated direction. >> >> The answering party is expected to try to start the call in the >> media/modality/direction combinations indicated with favoured parameters >> in the languages highest preferred by the offering party. What the >> answering party does if no match is possible for the highest favoured >> combinations, or if no combinations are marked as highest favoured is >> application dependent, and depending on the "humintlang-disposition" >> session level attribute. Answering parties may select other than the >> highest favoured combinations of the offer or add an interpreting agent, >> e.g. a relay service to arrange for a better match in languages and >> modalities in the call. The media/modalities/directions/languages selected >> for language communication by the answering party shall be indicated by >> "humintlang-send" and "humintlang-recv" attributes in the answer. If no >> match is possible, the value of the "humintlang-disposition" session level >> attribute should be interrogated by the answering party for the decision >> about how to handle the call. If the value is "reject", then the call MAY >> be rejected. There may however be application reasons to connect the call >> anyway. In that case the the humintlang-send actually intended to be used >> and the humintlang-recv value of the most likely combination to be >> initially used in the call shoud be included in the answer. Emergency >> calls should not be rejected because of language mismatch reasons. The >> mechanism provides a "favoured" modality parameter that MAY be included in >> the "humintlang-send" and "humintlang-recv" attribute values on media >> level. The "favoured" modality parameter is a keyword parameter with the >> name "favoured" and values "most" and "complement". >> >> This parameter is intended to be optionally included once for each >> combination of media, modality and direction of language. The indication >> is intended to carry the information that the indicated combination is >> the highest favoured alternative if the value is "most", and is a highly >> favoured complement to the most favoured modality in another media >> description if the value is "complement". The value "most" is allowed for >> more than one media/modality/direction combination for cases when it is >> essential for the indicating party to use more than one modality in the >> same direction. The "complement" value SHOULD not be used without any >> "most" value in the sdp, and should only be used for cases when the >> modality it is used with is supposed to be used for language transfer >> simultanously with the corresponding most favoured modality. >> >> The offering party is expected to include all supported languages >> in the offer. The answering party who can match sufficient >> languages/modalities and directions of the offering party, is expected to >> include in the answer the languages selected for initial use in the call >> and include the "favoured=most" parameter for the modalities that the call >> is intended to start with. If no match was found, then all supported >> languages should be included and the "favoured=most" parameter for the >> modalities that the call is intended to start with. >> >> o Mux Category: >> NORMAL >> >> o Reference: >> draft-ietf-slim-human-language-negotiation >> >> o Examples: (with shortened surrounding sdp) >> >> Offer: >> s=- >> a=humintlang-disposition: connect >> m=audio 34056 RTP/AVP 8 >> a=humintlang-send: modality=spoken favoured=most en fr >> m=video 36068 RTP/AVP 34 >> m=text 35072 RTP/AVP 102 >> a=humintlang-recv: modality=written favoured=most en fr >> a=humintlang-send: modality=written en fr >> >> Answer >> s=- >> a=humintlang-disposition: connect >> m=audio 34066 RTP/AVP 8 >> a=humintlang-recv: modality=spoken favoured=most en >> m=video 0 RTP/AVP 34 >> m=text 35092 RTP/AVP 102 >> a=humintlang-send: modality=written favoured=most en >> >> >> This sdp exchange indicates that the offering party wants the call to be >> connected regardless of the outcome of the negotiation, and that the most >> favoured modality and language is to speak English, but speaking French is >> also possible. >> The offering party also offers video, but with no intention to use it for >> language. >> The incoming language is preferred in written real-time text form. >> The offering party can accept to send English or French text if the other >> party is not capable of receiving spoken English. >> >> The answering party accepts to connect the call, and use the favoured >> modalities in English. No video capability is available, so the video >> offer is rejected, but the call connected, and the answering party can >> start with a written text greeting and expect to get spoken response. >> >> Note: Both the humintlang-disposition value "connect" and the modalities >> indicated are the default values, so they could in this case have been >> left out with the same result. >> >> -- >> -------------------------------------+------------------------------------- >> Reporter: | Owner: draft-ietf-slim- >> gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: negotiating-human- | Version: >> language | Keywords: Attribute >> Severity: - | >> -------------------------------------+------------------------------------- >> >> Ticket URL: >> slim >> >> _______________________________________________ >> 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 From nobody Fri Aug 12 13:11:46 2016 Return-Path: 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 B9AC112D5F7; Fri, 12 Aug 2016 13:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 cLZFqNyJOZZa; Fri, 12 Aug 2016 13:11:43 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6823412D8F9; Fri, 12 Aug 2016 13:11:43 -0700 (PDT) Received: from localhost ([::1]:40737 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bYInv-0008LP-8G; Fri, 12 Aug 2016 13:11:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Fri, 12 Aug 2016 20:11:43 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/10 Message-ID: <067.97128f3b6933cd72b025dad5505816d1@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160812201143.6823412D8F9@ietfa.amsl.com> Resent-Date: Fri, 12 Aug 2016 13:11:43 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #10 (negotiating-human-language): Summary of issues to the negotiating-human-language-04 draft X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 20:11:45 -0000 #10: Summary of issues to the negotiating-human-language-04 draft Here is a summary of the issues 2-9 to the negotiating-human-language-04 draft. 1. Move the session level parameter about rejecting or connecting the call in case of no language match to session level. There is no logically correct place for this parameter in the media level attributes. Issue #7. 2. Revert the default value of the rejecting or connecting the call at no match to be connecting. That matches the scope of the parameter better, and is in line with the discussion in the mail list. Issue #7 3. Add a value "improve" to the session level attribute, with the meaning "I can improve language matches by introduction of means not initially indicated. ( such as a caller not invoking a relay service initially, but after the answer when it shows that a relay service is needed. ) Issue #7. 4. Introduce a modality parameter in the humintlang-send and humintlang- recv attribute values. Default values handle most cases, but there are cases when an explicit value is needed, because it is not evident from the m-line and the language tag what modality indicated. This is especially true for m=application cases. (A complex alternative would be to specify all cases we know now explicitly of language use where it is not explicit by the mime type and the language tag what modality is intended, but I think that is too inflexible. ) Issue #6. 5. Combine all languages for one media, modality and direction in a space separated list as value to one humintlang-send or humintlang-recv attribute. That matches the format of the SIP Accept-Language field value. It also matches the logic of only indicating one highest favoured language. It would be possible to have only one language per humintlang-send or humintlang-recv attribute and include multiple attributes per media and direction. But then the syntax of the most favoured parameter gets less logical. Therefore I propose the changed attribute syntax. Issue #9. 6. Introduce a mark for most favoured media, meaning that the first language in the value list of the corresponding attribute is the most favoured for that direction. This can enable the negotiation to result in good decisions so that language exchange gets efficient. Without it, the start of the call will be in randomly selected modality and language among a set with undefined relative favour, causing problems to correct the modality and language when it gets initially wrong. Issue #6, #8 7. Allow indication of up to two highest favoured modalities per direction, or one highest favoured and one complementing, so that good decisions can be made. That enables specifying the needs behind the use of some common types of relay services or favoured behavior of the other party. Without this, there are calls that will not be answered in the most efficient way, instead causing confusion and delay. Issue #6,#8 8. Follow the format for attribute definition from rfc4566bis. Issue #9. 9. Wording change proposals: Issue #2, 3,4,5. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Keywords: Severity: In WG Last Call | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Fri Aug 12 13:14:50 2016 Return-Path: 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 D574E12D80D; Fri, 12 Aug 2016 13:14:48 -0700 (PDT) X-Quarantine-ID: <0iQXCu2n7S8y> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, T_FILL_THIS_FORM_SHORT=0.01] 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 0iQXCu2n7S8y; Fri, 12 Aug 2016 13:14:46 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7FB12B01B; Fri, 12 Aug 2016 13:14:46 -0700 (PDT) Received: from [192.168.1.25] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 12 Aug 2016 13:14:44 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Aug 2016 13:14:40 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Brian Rosen , slim issue tracker From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 20:14:49 -0000 Hi Gunnar, These create a complex mechanism that goes beyond=20 what we agreed to do for the initial version.=20 I'm happy to work with you on these mechanisms or=20 something else for a revision or extension. --Randy At 9:33 PM +0200 8/12/16, Gunnar Hellstr=F6m wrote: > Den 2016-08-09 kl. 15:06, skrev Brian Rosen: >> I agree that we need to conform to the 4566 template. >> >> I don't agree with changing the definition of the attribute. > I find it hard to see that you do not agree in=20 > any of the proposed changes in the definitions. > Here they are in a numbered list. > > 1. Move the session level parameter about=20 > rejecting or connecting the call in case of no=20 > language match to session level. There is no=20 > logically correct place for this parameter in=20 > the media level attributes. > > 2. Revert the default value of the rejecting or=20 > connecting the call at no match to be=20 > connecting. That matches the scope of the=20 > parameter better, and is in line with the=20 > discussion in the mail list. > > 3. Add a value "improve" to the session level=20 > attribute, with the meaning "I can improve=20 > language matches by introduction of means not=20 > initially indicated. ( such as a caller not=20 > invoking a relay service initially, but after=20 > the answer when it shows that a relay service=20 > is needed. ) > > 4. Introduce a modality parameter in the=20 > humintlang-send and humintlang-recv attribute=20 > values. Default values handle most cases, but=20 > there are cases when an explicit value is=20 > needed, because it is not evident from the=20 > m-line and the language tag what modality=20 > indicated. This is especially true for=20 > m=3Dapplication cases. > (A complex alternative would be to specify all=20 > cases we know now explicitly of language use=20 > where it is not explicit by the mime type and=20 > the language tag what modality is intended, but=20 > I think that is too inflexible. ) > > 5. Combine all languages for one media,=20 > modality and direction in a space separated=20 > list as value to one humintlang-send or=20 > humintlang-recv attribute. That matches the=20 > format of the SIP Accept-Language field value. > It also matches the logic of only indicating one highest favoured languag= e. > It would be possible to have only one language=20 > per humintlang-send or humintlang-recv=20 > attribute and include multiple attributes per=20 > media and direction. But then the syntax of the=20 > most favoured parameter gets less logical.=20 > Therefore I propose the changed attribute=20 > syntax. > > 6. Introduce a mark for most favoured media,=20 > meaning that the first language in the value=20 > list of the corresponding attribute is the most=20 > favoured for that direction. This can enable=20 > the negotiation to result in good decisions so=20 > that language exchange gets efficient. Without=20 > it, the start of the call will be in randomly=20 > selected modality and language among a set with=20 > undefined relative favour, causing problems to=20 > correct the modality and language when it gets=20 > initially wrong. > > 7. Allow indication of up to two highest=20 > favoured modalities per direction, or one=20 > highest favoured and one complementing, so that=20 > good decisions can be made. > That enables specifying the needs behind the=20 > use of some common types of relay services or=20 > favoured behavior of the other party. Without=20 > this, there are calls that will not be answered=20 > in the most efficient way, instead causing=20 > confusion and delay. > > > Regards > > Gunnar > > > >> >> Brian >> >> >>> On Aug 9, 2016, at 4:49 AM, slim issue=20 >>> tracker wrote: >>> >>> #9: Attribute specifications following the layout required by RFC4566bi= s >>> >>> The attribute specifications need to be more formal than in the current >>> draft (-04 ) >>> >>> The following is required from attribute specifications according to RF= C >>> 4566bis, section 8.2.4.1: >>> >>> >>> >>> "New attribute registrations are accepted according to the >>> "Specification Required" policy of [RFC5226], provided that the >>> specification includes the following information: >>> >>> o Contact Name. >>> >>> o Contact Email Address. >>> >>> o Attribute Name: The name of the attribute that will appear in >>> SDP). This MUST conform to the definition of . >>> >>> o Attribute Syntax: For a value attribute (see clause 5.13), an AB= NF >>> definition of the attribute value syntax (See >>> Section Section 9) MUST be provided. The syntax MUST follow the >>> rule form as per Section 2.2 of [RFC5234]. This SHALL define th= e >>> allowable values that the attribute might take. It MAY also >>> define an extension method for the addition of future values. F= or >>> a property attribute, the ABNF definition is omitted as the >>> property attribute takes no values. >>> >>> o Attribute Semantics: For a value attribute, a semantic descripti= on >>> of the values that the attribute might take MUST be provided. T= he >>> usage of a property attribute is described under purpose below. >>> >>> o Attribute Value: The name of an ABNF syntax rule defining the >>> syntax of the value. Absence of a rule name indicates that the >>> attribute takes no values. Enclosing the rule name in "[" and "= ]" >>> indicates that a value is optional. >>> >>> o Usage Level: Usage level(s) of the attribute. One or more of: >>> session, media, source, dcsa, dcsa(subprotocol). For a definiti= on >>> of source level attributes, see [RFC5576]. For a definition of >>> dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. >>> >>> o Charset Dependent: Whether the attribute value is subject to the >>> charset attribute or not (Yes/No). >>> >>> o Purpose: An explanation of the purpose and usage of the attribut= e. >>> >>> o O/A Procedures: Offer/Answer procedures as explained in [RFC3264= ]. >>> >>> o Mux Category: Indication of which multiplexing "category" >>> [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated >>> with. >>> >>> o Reference: A reference to the specification defining the >>> attribute. >>> " >>> >>> >>> --------------------------------------------------------------- >>> Change. Add chapters on the attributes in the format described in >>> RFC4566bis, section 8.2.4.1 >>> >>> Some changes are also needed in the earlier text in the draft to align >>> with these attribute specifications. >>> -------------------------------------------------------------------- >>> >>> >>> x. Specification of the "humintlang-disposition" attribute >>> >>> o Contact Name. >>> XXXXXXXXXXXXXXXXXXXXXXXXXXXX >>> >>> o Contact Email Address. >>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>> >>> o Attribute Name: >>> humintlang-disposition >>> >>> o Attribute Syntax: >>> humintlang-disposition =3D "a=3Dhumintlang-disposition" HCOLON disp= osition >>> >>> o Attribute Semantics: >>> If no match is possible, the value of the "humintlang-disposition" >>> session level attribute should be interrogated by the answering party f= or >>> the decision about how to handle the call. If the value is "reject", th= en >>> the call MAY be rejected. There may however be application reasons to >>> connect the call anyway. In that case the the humintlang-send actually >>> intended to be used and the humintlang-recv value of the most likely >>> combination to be initially used in the call shoud be included in the >>> answer. Emergency calls should not be rejected because of language >>> mismatch reasons. >>> >>> If the value of the "humintlang-disposition" session level >>> attribute is "improve", then the party who inserted that value has some >>> means to improve the match e.g. by adding an interpreting agent, e.g. a >>> relay service. An answering party detecting the "improve" value may the= n >>> connect the call, insert all its non-matching humintlang-send and >>> humintlang-recv values and look forward to receiving new sdp with possi= bly >>> better match. The offering party, or a service provider along the call >>> path, detecting in the answer that the media/modality/direction/languag= e >>> indications did not match, may act to improve the match, e.g. by adding= an >>> interpreting agent, e.g. a relay service, to arrange for a better match= =2E >>> The parties involved in the call shall be informed about the result of >>> such actions by new sdp with new values in the humintlang attributes. T= he >>> mechanisms for such detection, decision and modifications of the call a= re >>> out of scope for this specification. The ability to use such mechanisms >>> shall be indicated by the value "improve" in the "humintlang-dispositio= n" >>> session attribute. >>> >>> When the value of the "humintlang-disposition" is "connect" (t= hat >>> is also the default value), then the call should be connected even with= out >>> matching language/modality/direction indications. In that case the the >>> humintlang-send actually intended to be used and the humintlang-recv va= lue >>> of the most likely combination to be initially used in the call shoud b= e >>> included in the answer. The connected parties may use in-band actions t= o >>> figure out if they have any human language communication means that ful= fil >>> the intentions of the call. >>> >>> o Attribute Value: >>> disposition =3D "reject"/"complete"/"improve"/disposition-extension >>> disposition-extension =3D token >>> The value "complete" is default. >>> >>> o Usage Level: >>> session >>> >>> o Charset Dependent: No. >>> >>> o Purpose: >>> The attribute specifies how to handle the call when no language or >>> modality match is found. >>> >>> >>> o O/A Procedures: >>> If no match is possible, the value of the "humintlang-disposit= ion" >>> session level attribute should be interrogated by the answering party f= or >>> the decision about how to handle the call. If the value is "reject", th= en >>> the call MAY be rejected. There may however be application reasons to >>> connect the call anyway. In that case the the humintlang-send actually >>> intended to be used and the humintlang-recv value of the most likely >>> combination to be initially used in the call shoud be included in the >>> answer. Emergency calls should not be rejected because of language >>> mismatch reasons. >>> >>> An answering party detecting the "improve" value may then conn= ect >>> the call, insert all its non-matching humintlang-send and humintlang-re= cv >>> values and look forward to receiving new sdp with possibly better match= =2E >>> The offering party, or a service provider along the call path, detectin= g >>> in the answer that the media/modality/direction/language indications di= d >>> not match, may act to improve the match, e.g. by adding an interpreting >>> agent, e.g. a relay service, to arrange for a better match. The parties >>> involved in the call shall be informed about the result of such actions= by >>> new sdp with new values in the humintlang attributes. >>> >>> When the value of the "humintlang-disposition" is "connect" (t= hat >>> is also the default value), then the call should be connected even with= out >>> matching language/modality/direction indications. In that case the the >>> humintlang-send actually intended to be used and the humintlang-recv va= lue >>> of the most likely combination to be initially used in the call shoud b= e >>> included in the answer. >>> >>> o Mux Category: >>> NORMAL >>> >>> o Reference: >>> >>> draft-ietf-slim-human-language-negotiation >>> >>> o Example: >>> See the example for the humintlang-send and humintlang-recv attribu= tes. >>> >>> >>> >>> Y. Specification of the humintlang-send and humintlang-recv attributes >>> >>> o Contact Name. >>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>> >>> o Contact Email Address. >>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>> >>> o Attribute Name: >>> humintlang-recv >>> >>> humintlang-send >>> >>> >>> >>> o Attribute Syntax: >>> humintlang-send =3D "a=3Dhumintlang-send" HCOLON [humintlang= -value] >>> >>> humintlang-recv =3D "a=3Dhumintlang-recv" HCOLON [humintlang= -value] >>> >>> When used without language parameter, the humintlang-send and >>> humntlang-recv attribute indicates modality and direction for use with = the >>> default language of the area and media or media/subprotocol. >>> >>> >>> o Attribute Semantics: >>> In order to successfully start a call, the parties need to be aware= of >>> which language capabilities were negotiated, and also which modality th= e >>> parties prefer to use. A call can start without hesitation and be >>> conducted smoothly only when answered with the modality and language th= at >>> best matches the most favoured combinations by the caller. There is a >>> tendency among call participants to continue using the modality first u= sed >>> in a call, even if that is not the most favoured modality. The call >>> participants usually want to communicate about the topic of the call, a= nd >>> not about how the call will be performed. Therefore, a mechanism is >>> provided for indication of most preferred modality/modalities of the ca= ll >>> participants together with the language attributes. >>> >>> The humintlang-send attribute indicates modality and language >>> preferences for transmission from the indicating party. >>> The humintlang-recv attribute indicates modality and language >>> preferences for reception by the indicating party. >>> >>> The mechanism provides a "favoured" modality parameter that= MAY be >>> included in the "humintlang-send" and "humintlang-recv" attribute value= s >>> on media level. The "favoured" modality parameter is a keyword paramete= r >>> with the name "favoured" and values "most" and "complement". >>> >>> The "favoured" parameter is intended to be optionally included >>> once for each combination of media, modality and direction of language. >>> The indication is intended to carry the information that the indicated >>> combination is the highest favoured alternative if the value is "most", >>> and is a highly favoured complement to the most favoured modality in >>> another media description if the value is "complement". The value "most= " >>> is allowed for more than one media/modality/direction combination for >>> cases when it is essential for the indicating party to use more than on= e >>> modality in the same direction. The "complement" value SHOULD not be us= ed >>> without any "most" value in the sdp, and should only be used for cases >>> when the modality it is used with is supposed to be used for language >>> transfer simultanously with the corresponding most favoured modality. >>> >>> The language parameter is an optional list of languages that t= he >>> indicating party is prepared to use in the indicated media, modality an= d >>> direction. The list is a whitespace separated list of language tags >>> arranged in preference order, with highest preferred first. >>> >>> >>> o Attribute Value: >>> >>> humintlang-value =3D[*humintlang-param][*language] >>> humintlang-param =3D [modality][favoured] >>> modality =3D "modality=3D" ("spoken"/"signed"/"written"/modali= ty- >>> extension) >>> The value "spoken" is default for audio media. >>> The value "signed" is default for video media except when used >>> with a spoken or written language. >>> The value "spoken" is default for video media when used with >>> spoken language. >>> The value "written" is default for text media >>> favoured=3D "favoured=3D"("most"/"complement") >>> modality-extension =3D token >>> Modalities can be extended with further modalities and assigne= d >>> values indicated >>> language =3D Language-Tag >>> where Language-Tag is defined in RFC 5646, Section 2.1. >>> >>> >>> o Usage Level: >>> media, dcsa(subprotocol). >>> dcsa(T140) can be indicated to carry text modality. >>> >>> o Charset Dependent: No >>> >>> o Purpose: >>> In order to successfully start a call, the parties need to be= aware of >>> which language capabilities were negotiated, and also which modality th= e >>> parties prefer to use. A call can start without hesitation and be >>> conducted smoothly only when answered with the modality and language th= at >>> best matches the most favoured combinations by the caller. The attribut= es >>> are intended to carry the information about supported and favoured >>> languages and modalities between the communicating parties. >>> >>> o O/A Procedures: >>> Offering parties who strongly favour specific ways to communic= ate >>> by language are expected to indicate these ways using the humintlang-se= nd >>> or humintlang-recv attributes with the "favoured=3Dmost" parameter on t= he >>> most favoured media/modality/direction combination(s). A "favoured=3Dmo= st" >>> indication may be included for all media/modality/direction combination= s >>> that are eagerly wanted together (usually one or two per direction). If >>> one media/modality/direction is wanted together with a most favoured >>> combination but with lower urgency, then the "favoured=3Dcomplement" sh= ould >>> be indicated (usually none or one per direction). Other >>> media/modality/direction combinations SHALL be left without the "favour= ed" >>> indication. >>> >>> When only one language indication for a direction in the whole= sdp >>> is indicated, it is regarded to be the most favoured language for the >>> indicated direction. >>> >>> The answering party is expected to try to start the call in th= e >>> media/modality/direction combinations indicated with favoured parameter= s >>> in the languages highest preferred by the offering party. What the >>> answering party does if no match is possible for the highest favoured >>> combinations, or if no combinations are marked as highest favoured is >>> application dependent, and depending on the "humintlang-disposition" >>> session level attribute. Answering parties may select other than the >>> highest favoured combinations of the offer or add an interpreting agent= , >>> e.g. a relay service to arrange for a better match in languages and >>> modalities in the call. The media/modalities/directions/languages selec= ted >>> for language communication by the answering party shall be indicated by >>> "humintlang-send" and "humintlang-recv" attributes in the answer. If no >>> match is possible, the value of the "humintlang-disposition" session le= vel >>> attribute should be interrogated by the answering party for the decisio= n >>> about how to handle the call. If the value is "reject", then the call M= AY >>> be rejected. There may however be application reasons to connect the ca= ll >>> anyway. In that case the the humintlang-send actually intended to be us= ed >>> and the humintlang-recv value of the most likely combination to be >>> initially used in the call shoud be included in the answer. Emergency >>> calls should not be rejected because of language mismatch reasons. T= he >>> mechanism provides a "favoured" modality parameter that MAY be included= in >>> the "humintlang-send" and "humintlang-recv" attribute values on media >>> level. The "favoured" modality parameter is a keyword parameter with th= e >>> name "favoured" and values "most" and "complement". >>> >>> This parameter is intended to be optionally included once for = each >>> combination of media, modality and direction of language. The indicatio= n >>> is intended to carry the information that the indicated combination= is >>> the highest favoured alternative if the value is "most", and is a highl= y >>> favoured complement to the most favoured modality in another media >>> description if the value is "complement". The value "most" is allowed f= or >>> more than one media/modality/direction combination for cases when it is >>> essential for the indicating party to use more than one modality in the >>> same direction. The "complement" value SHOULD not be used without any >>> "most" value in the sdp, and should only be used for cases when the >>> modality it is used with is supposed to be used for language transfer >>> simultanously with the corresponding most favoured modality. >>> >>> The offering party is expected to include all supported langua= ges >>> in the offer. The answering party who can match sufficient >>> languages/modalities and directions of the offering party, is expected = to >>> include in the answer the languages selected for initial use in the cal= l >>> and include the "favoured=3Dmost" parameter for the modalities that the= call >>> is intended to start with. If no match was found, then all supported >>> languages should be included and the "favoured=3Dmost" parameter for th= e >>> modalities that the call is intended to start with. >>> >>> o Mux Category: >>> NORMAL >>> >>> o Reference: >>> draft-ietf-slim-human-language-negotiation >>> >>> o Examples: (with shortened surrounding sdp) >>> >>> Offer: >>> s=3D- >>> a=3Dhumintlang-disposition: connect >>> m=3Daudio 34056 RTP/AVP 8 >>> a=3Dhumintlang-send: modality=3Dspoken favoured=3Dmost en fr >>> m=3Dvideo 36068 RTP/AVP 34 >>> m=3Dtext 35072 RTP/AVP 102 >>> a=3Dhumintlang-recv: modality=3Dwritten favoured=3Dmost en fr >>> a=3Dhumintlang-send: modality=3Dwritten en fr >>> >>> Answer >>> s=3D- >>> a=3Dhumintlang-disposition: connect >>> m=3Daudio 34066 RTP/AVP 8 >>> a=3Dhumintlang-recv: modality=3Dspoken favoured=3Dmost en >>> m=3Dvideo 0 RTP/AVP 34 >>> m=3Dtext 35092 RTP/AVP 102 >>> a=3Dhumintlang-send: modality=3Dwritten favoured=3Dmost en >>> >>> >>> This sdp exchange indicates that the offering party wants the call to b= e >>> connected regardless of the outcome of the negotiation, and that the mo= st >>> favoured modality and language is to speak English, but speaking French= is >>> also possible. >>> The offering party also offers video, but with no intention to use it f= or >>> language. >>> The incoming language is preferred in written real-time text form. >>> The offering party can accept to send English or French text if the oth= er >>> party is not capable of receiving spoken English. >>> >>> The answering party accepts to connect the call, and use the favoured >>> modalities in English. No video capability is available, so the video >>> offer is rejected, but the call connected, and the answering party can >>> start with a written text greeting and expect to get spoken response. >>> >>> Note: Both the humintlang-disposition value "connect" and the modalitie= s >>> indicated are the default values, so they could in this case have been >>> left out with the same result. >>> >>> -- >>> -------------------------------------+---------------------------------= ---- >>> Reporter: | Owner: draft-ietf-slim- >>> gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf= =2Eorg >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: negotiating-human- | Version: >>> language | Keywords: Attribute >>> Severity: - | >>> -------------------------------------+---------------------------------= ---- >>> >>> Ticket URL: >>> slim >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It has been observed that one's nose is never so happy as when it is thrust into the affairs of another, from which some physiologists have drawn the inference that the nose is devoid of the sense of smell. --Ambrose Bierce, "The Devil's Dictionary" From nobody Fri Aug 12 13:58:50 2016 Return-Path: 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 49A6E12D0A4 for ; Fri, 12 Aug 2016 13:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 PWvdO8OiTUoU for ; Fri, 12 Aug 2016 13:58:45 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D0412B03C for ; Fri, 12 Aug 2016 13:58:45 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id x25so18195428qtx.2 for ; Fri, 12 Aug 2016 13:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/352P7rncnw58Cd+a7Q2de2fxpJEU9LkqPXT8JtA604=; b=kXiWbfP87hbBgyOsNRaAgPCqxlwN2kq9BHhT8p4pkS9p7MjFFPrjG0ZIxGbY2QiTd2 nW67+tWLHFHJXUJtLxnn4dFHHK85qssT/qhs3Ee+zFNw4FWzPXyYvossE9lZh/WXx+aM gsQTSKc8seSpRVTbMG3ApwMwnOpAteukTf7qsnBBBQjZUC/cTX3V9z69wqkzr75WXicJ JJ8C/MpUrhiT7Qs7EKy+rFzyQbijhRmoV6poB+fyHE2jpY/ujCmvtV0958RmRnyk13H2 hcYwZr6Q+WZX1ohRenNE1EEYqCw4ubxSGrApIk4rm5XyffhvkP/b0U/A65tHt3yjL8GH QDSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/352P7rncnw58Cd+a7Q2de2fxpJEU9LkqPXT8JtA604=; b=QZXZ9GBWxyBYBQDkLhx+oborMxqFjBSLmj2iyOMBkXgVzQ73Vim9VlB3r9KJ2oknHC V9Q/87objWlA/E+qjTxgG1v9hN8M6Zu1dLdr2kIeR6kBa7hIXpCRRRgP4sImP8WXl4Kk gPRD+WI7D/Hz+hgLNiezlibxr9kw19qYnJF0JWLLbMfDaJzaoR6Y2w7CidyrzR3XhxOh d0CKQViJr5aBfw7ZyLt5ixZFbnpt2rd3xeHrblND9bUxSBiVn3Qz6Ad9rs3gqOn7WoXT 3/+pd43xg7zuY7BzVae7xjf0oPNlU9fdGMoLQI3L63uhy/csBEU7aVNkffK7hXFCTehy nCQg== X-Gm-Message-State: AEkooutt0i0ZwYvVnsRUyIoHtQN8+pBOQOuU8PJgh0Ys1aqQR2b24Ikp8ZxcNJGBEAqkrA== X-Received: by 10.200.46.122 with SMTP id s55mr19983513qta.80.1471035523963; Fri, 12 Aug 2016 13:58:43 -0700 (PDT) Received: from [10.33.193.48] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id u44sm5408720qtc.27.2016.08.12.13.58.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Aug 2016 13:58:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 12 Aug 2016 16:58:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> To: Randall Gellens , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 20:58:49 -0000 I agree. Some detail below > On Aug 12, 2016, at 4:14 PM, Randall Gellens = wrote: >=20 > Hi Gunnar, >=20 > These create a complex mechanism that goes beyond=20 > what we agreed to do for the initial version.=20 > I'm happy to work with you on these mechanisms or=20 > something else for a revision or extension. >=20 > --Randy >=20 > At 9:33 PM +0200 8/12/16, Gunnar Hellstr=C3=B6m wrote: >=20 >> Den 2016-08-09 kl. 15:06, skrev Brian Rosen: >>> I agree that we need to conform to the 4566 template. >>>=20 >>> I don't agree with changing the definition of the attribute. >> I find it hard to see that you do not agree in=20 >> any of the proposed changes in the definitions. >> Here they are in a numbered list. >>=20 >> 1. Move the session level parameter about=20 >> rejecting or connecting the call in case of no=20 >> language match to session level. There is no=20 >> logically correct place for this parameter in=20 >> the media level attributes. I=E2=80=99m not worried about having this be at a media level. The = recipient can always reject the call for whatever reason it wants. The = sender can always drop the call if it doesn=E2=80=99t like the result of = negotiations. t could easily construct use cases where what you want is = media decisions, not session decisions (so, if you can=E2=80=99t give me = English text, I don=E2=80=99t care if you can give me Spanish video, I = want to fail the call). It=E2=80=99s all advisory, and I=E2=80=99d = prefer to keep it where it is. >>=20 >> 2. Revert the default value of the rejecting or=20 >> connecting the call at no match to be=20 >> connecting. That matches the scope of the=20 >> parameter better, and is in line with the=20 >> discussion in the mail list. I don=E2=80=99t really care about this. Again, this is at best = advisory, and either end can reject any time. If you rely on defaults = to get what you want, you deserve what you get. >>=20 >> 3. Add a value "improve" to the session level=20 >> attribute, with the meaning "I can improve=20 >> language matches by introduction of means not=20 >> initially indicated. ( such as a caller not=20 >> invoking a relay service initially, but after=20 >> the answer when it shows that a relay service=20 >> is needed. ) I am strongly against doing this ever. If you need to renegotiate, drop = the call and try again, probably with some different path (i.e. with = relay). >>=20 >> 4. Introduce a modality parameter in the=20 >> humintlang-send and humintlang-recv attribute=20 >> values. Default values handle most cases, but=20 >> there are cases when an explicit value is=20 >> needed, because it is not evident from the=20 >> m-line and the language tag what modality=20 >> indicated. This is especially true for=20 >> m=3Dapplication cases. >> (A complex alternative would be to specify all=20 >> cases we know now explicitly of language use=20 >> where it is not explicit by the mime type and=20 >> the language tag what modality is intended, but=20 >> I think that is too inflexible. ) I am strongly against doing this ever. I think it=E2=80=99s a bad idea. = =20 >>=20 >> 5. Combine all languages for one media,=20 >> modality and direction in a space separated=20 >> list as value to one humintlang-send or=20 >> humintlang-recv attribute. That matches the=20 >> format of the SIP Accept-Language field value. >> It also matches the logic of only indicating one highest favoured = language. >> It would be possible to have only one language=20 >> per humintlang-send or humintlang-recv=20 >> attribute and include multiple attributes per=20 >> media and direction. But then the syntax of the=20 >> most favoured parameter gets less logical.=20 >> Therefore I propose the changed attribute=20 >> syntax. I am strongly against doing this at this time. I=E2=80=99m not sure if = makes any sense, and I=E2=80=99d like to get some experience before we = make decisions in this area. >>=20 >> 6. Introduce a mark for most favoured media,=20 >> meaning that the first language in the value=20 >> list of the corresponding attribute is the most=20 >> favoured for that direction. This can enable=20 >> the negotiation to result in good decisions so=20 >> that language exchange gets efficient. Without=20 >> it, the start of the call will be in randomly=20 >> selected modality and language among a set with=20 >> undefined relative favour, causing problems to=20 >> correct the modality and language when it gets=20 >> initially wrong. I really don=E2=80=99t think this is the best way to handle interactions = between media, but regardless, at this time, I don=E2=80=99t think we = should have mechanisms like this. >>=20 >> 7. Allow indication of up to two highest=20 >> favoured modalities per direction, or one=20 >> highest favoured and one complementing, so that=20 >> good decisions can be made. >> That enables specifying the needs behind the=20 >> use of some common types of relay services or=20 >> favoured behavior of the other party. Without=20 >> this, there are calls that will not be answered=20 >> in the most efficient way, instead causing=20 >> confusion and delay. I am strongly against doing this at this time. I doubt this will ever = be the right answer, but at least now, I we had consensus not to have = mechanisms like this in the document. >>=20 >>=20 >> Regards >>=20 >> Gunnar >>=20 >>=20 >>=20 >>>=20 >>> Brian >>>=20 >>>=20 >>>> On Aug 9, 2016, at 4:49 AM, slim issue=20 >>>> tracker wrote: >>>>=20 >>>> #9: Attribute specifications following the layout required by = RFC4566bis >>>>=20 >>>> The attribute specifications need to be more formal than in the = current >>>> draft (-04 ) >>>>=20 >>>> The following is required from attribute specifications according = to RFC >>>> 4566bis, section 8.2.4.1: >>>>=20 >>>>=20 >>>>=20 >>>> "New attribute registrations are accepted according to the >>>> "Specification Required" policy of [RFC5226], provided that the >>>> specification includes the following information: >>>>=20 >>>> o Contact Name. >>>>=20 >>>> o Contact Email Address. >>>>=20 >>>> o Attribute Name: The name of the attribute that will appear = in >>>> SDP). This MUST conform to the definition of . >>>>=20 >>>> o Attribute Syntax: For a value attribute (see clause 5.13), = an ABNF >>>> definition of the attribute value syntax (See >>>> Section Section 9) MUST be provided. The syntax MUST follow = the >>>> rule form as per Section 2.2 of [RFC5234]. This SHALL = define the >>>> allowable values that the attribute might take. It MAY also >>>> define an extension method for the addition of future = values. For >>>> a property attribute, the ABNF definition is omitted as the >>>> property attribute takes no values. >>>>=20 >>>> o Attribute Semantics: For a value attribute, a semantic = description >>>> of the values that the attribute might take MUST be = provided. The >>>> usage of a property attribute is described under purpose = below. >>>>=20 >>>> o Attribute Value: The name of an ABNF syntax rule defining = the >>>> syntax of the value. Absence of a rule name indicates that = the >>>> attribute takes no values. Enclosing the rule name in "[" = and "]" >>>> indicates that a value is optional. >>>>=20 >>>> o Usage Level: Usage level(s) of the attribute. One or more = of: >>>> session, media, source, dcsa, dcsa(subprotocol). For a = definition >>>> of source level attributes, see [RFC5576]. For a definition = of >>>> dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. >>>>=20 >>>> o Charset Dependent: Whether the attribute value is subject to = the >>>> charset attribute or not (Yes/No). >>>>=20 >>>> o Purpose: An explanation of the purpose and usage of the = attribute. >>>>=20 >>>> o O/A Procedures: Offer/Answer procedures as explained in = [RFC3264]. >>>>=20 >>>> o Mux Category: Indication of which multiplexing "category" >>>> [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is = associated >>>> with. >>>>=20 >>>> o Reference: A reference to the specification defining the >>>> attribute. >>>> " >>>>=20 >>>>=20 >>>> --------------------------------------------------------------- >>>> Change. Add chapters on the attributes in the format described in >>>> RFC4566bis, section 8.2.4.1 >>>>=20 >>>> Some changes are also needed in the earlier text in the draft to = align >>>> with these attribute specifications. >>>> = -------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> x. Specification of the "humintlang-disposition" attribute >>>>=20 >>>> o Contact Name. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>=20 >>>> o Contact Email Address. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>=20 >>>> o Attribute Name: >>>> humintlang-disposition >>>>=20 >>>> o Attribute Syntax: >>>> humintlang-disposition =3D "a=3Dhumintlang-disposition" HCOLON = disposition >>>>=20 >>>> o Attribute Semantics: >>>> If no match is possible, the value of the = "humintlang-disposition" >>>> session level attribute should be interrogated by the answering = party for >>>> the decision about how to handle the call. If the value is = "reject", then >>>> the call MAY be rejected. There may however be application reasons = to >>>> connect the call anyway. In that case the the humintlang-send = actually >>>> intended to be used and the humintlang-recv value of the most = likely >>>> combination to be initially used in the call shoud be included in = the >>>> answer. Emergency calls should not be rejected because of language >>>> mismatch reasons. >>>>=20 >>>> If the value of the "humintlang-disposition" session level >>>> attribute is "improve", then the party who inserted that value has = some >>>> means to improve the match e.g. by adding an interpreting agent, = e.g. a >>>> relay service. An answering party detecting the "improve" value may = then >>>> connect the call, insert all its non-matching humintlang-send and >>>> humintlang-recv values and look forward to receiving new sdp with = possibly >>>> better match. The offering party, or a service provider along the = call >>>> path, detecting in the answer that the = media/modality/direction/language >>>> indications did not match, may act to improve the match, e.g. by = adding an >>>> interpreting agent, e.g. a relay service, to arrange for a better = match. >>>> The parties involved in the call shall be informed about the result = of >>>> such actions by new sdp with new values in the humintlang = attributes. The >>>> mechanisms for such detection, decision and modifications of the = call are >>>> out of scope for this specification. The ability to use such = mechanisms >>>> shall be indicated by the value "improve" in the = "humintlang-disposition" >>>> session attribute. >>>>=20 >>>> When the value of the "humintlang-disposition" is = "connect" (that >>>> is also the default value), then the call should be connected even = without >>>> matching language/modality/direction indications. In that case the = the >>>> humintlang-send actually intended to be used and the = humintlang-recv value >>>> of the most likely combination to be initially used in the call = shoud be >>>> included in the answer. The connected parties may use in-band = actions to >>>> figure out if they have any human language communication means that = fulfil >>>> the intentions of the call. >>>>=20 >>>> o Attribute Value: >>>> disposition =3D = "reject"/"complete"/"improve"/disposition-extension >>>> disposition-extension =3D token >>>> The value "complete" is default. >>>>=20 >>>> o Usage Level: >>>> session >>>>=20 >>>> o Charset Dependent: No. >>>>=20 >>>> o Purpose: >>>> The attribute specifies how to handle the call when no language = or >>>> modality match is found. >>>>=20 >>>>=20 >>>> o O/A Procedures: >>>> If no match is possible, the value of the = "humintlang-disposition" >>>> session level attribute should be interrogated by the answering = party for >>>> the decision about how to handle the call. If the value is = "reject", then >>>> the call MAY be rejected. There may however be application reasons = to >>>> connect the call anyway. In that case the the humintlang-send = actually >>>> intended to be used and the humintlang-recv value of the most = likely >>>> combination to be initially used in the call shoud be included in = the >>>> answer. Emergency calls should not be rejected because of language >>>> mismatch reasons. >>>>=20 >>>> An answering party detecting the "improve" value may then = connect >>>> the call, insert all its non-matching humintlang-send and = humintlang-recv >>>> values and look forward to receiving new sdp with possibly better = match. >>>> The offering party, or a service provider along the call path, = detecting >>>> in the answer that the media/modality/direction/language = indications did >>>> not match, may act to improve the match, e.g. by adding an = interpreting >>>> agent, e.g. a relay service, to arrange for a better match. The = parties >>>> involved in the call shall be informed about the result of such = actions by >>>> new sdp with new values in the humintlang attributes. >>>>=20 >>>> When the value of the "humintlang-disposition" is = "connect" (that >>>> is also the default value), then the call should be connected even = without >>>> matching language/modality/direction indications. In that case the = the >>>> humintlang-send actually intended to be used and the = humintlang-recv value >>>> of the most likely combination to be initially used in the call = shoud be >>>> included in the answer. >>>>=20 >>>> o Mux Category: >>>> NORMAL >>>>=20 >>>> o Reference: >>>>=20 >>>> draft-ietf-slim-human-language-negotiation >>>>=20 >>>> o Example: >>>> See the example for the humintlang-send and humintlang-recv = attributes. >>>>=20 >>>>=20 >>>>=20 >>>> Y. Specification of the humintlang-send and humintlang-recv = attributes >>>>=20 >>>> o Contact Name. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>=20 >>>> o Contact Email Address. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>=20 >>>> o Attribute Name: >>>> humintlang-recv >>>>=20 >>>> humintlang-send >>>>=20 >>>>=20 >>>>=20 >>>> o Attribute Syntax: >>>> humintlang-send =3D "a=3Dhumintlang-send" HCOLON = [humintlang-value] >>>>=20 >>>> humintlang-recv =3D "a=3Dhumintlang-recv" HCOLON = [humintlang-value] >>>>=20 >>>> When used without language parameter, the humintlang-send = and >>>> humntlang-recv attribute indicates modality and direction for use = with the >>>> default language of the area and media or media/subprotocol. >>>>=20 >>>>=20 >>>> o Attribute Semantics: >>>> In order to successfully start a call, the parties need to be = aware of >>>> which language capabilities were negotiated, and also which = modality the >>>> parties prefer to use. A call can start without hesitation and be >>>> conducted smoothly only when answered with the modality and = language that >>>> best matches the most favoured combinations by the caller. There is = a >>>> tendency among call participants to continue using the modality = first used >>>> in a call, even if that is not the most favoured modality. The call >>>> participants usually want to communicate about the topic of the = call, and >>>> not about how the call will be performed. Therefore, a mechanism is >>>> provided for indication of most preferred modality/modalities of = the call >>>> participants together with the language attributes. >>>>=20 >>>> The humintlang-send attribute indicates modality and = language >>>> preferences for transmission from the indicating party. >>>> The humintlang-recv attribute indicates modality and = language >>>> preferences for reception by the indicating party. >>>>=20 >>>> The mechanism provides a "favoured" modality parameter = that MAY be >>>> included in the "humintlang-send" and "humintlang-recv" attribute = values >>>> on media level. The "favoured" modality parameter is a keyword = parameter >>>> with the name "favoured" and values "most" and "complement". >>>>=20 >>>> The "favoured" parameter is intended to be optionally = included >>>> once for each combination of media, modality and direction of = language. >>>> The indication is intended to carry the information that the = indicated >>>> combination is the highest favoured alternative if the value is = "most", >>>> and is a highly favoured complement to the most favoured modality = in >>>> another media description if the value is "complement". The value = "most" >>>> is allowed for more than one media/modality/direction combination = for >>>> cases when it is essential for the indicating party to use more = than one >>>> modality in the same direction. The "complement" value SHOULD not = be used >>>> without any "most" value in the sdp, and should only be used for = cases >>>> when the modality it is used with is supposed to be used for = language >>>> transfer simultanously with the corresponding most favoured = modality. >>>>=20 >>>> The language parameter is an optional list of languages = that the >>>> indicating party is prepared to use in the indicated media, = modality and >>>> direction. The list is a whitespace separated list of language tags >>>> arranged in preference order, with highest preferred first. >>>>=20 >>>>=20 >>>> o Attribute Value: >>>>=20 >>>> humintlang-value =3D[*humintlang-param][*language] >>>> humintlang-param =3D [modality][favoured] >>>> modality =3D "modality=3D" = ("spoken"/"signed"/"written"/modality- >>>> extension) >>>> The value "spoken" is default for audio media. >>>> The value "signed" is default for video media except when = used >>>> with a spoken or written language. >>>> The value "spoken" is default for video media when used = with >>>> spoken language. >>>> The value "written" is default for text media >>>> favoured=3D "favoured=3D"("most"/"complement") >>>> modality-extension =3D token >>>> Modalities can be extended with further modalities and = assigned >>>> values indicated >>>> language =3D Language-Tag >>>> where Language-Tag is defined in RFC 5646, Section 2.1. >>>>=20 >>>>=20 >>>> o Usage Level: >>>> media, dcsa(subprotocol). >>>> dcsa(T140) can be indicated to carry text modality. >>>>=20 >>>> o Charset Dependent: No >>>>=20 >>>> o Purpose: >>>> In order to successfully start a call, the parties need to be = aware of >>>> which language capabilities were negotiated, and also which = modality the >>>> parties prefer to use. A call can start without hesitation and be >>>> conducted smoothly only when answered with the modality and = language that >>>> best matches the most favoured combinations by the caller. The = attributes >>>> are intended to carry the information about supported and favoured >>>> languages and modalities between the communicating parties. >>>>=20 >>>> o O/A Procedures: >>>> Offering parties who strongly favour specific ways to = communicate >>>> by language are expected to indicate these ways using the = humintlang-send >>>> or humintlang-recv attributes with the "favoured=3Dmost" parameter = on the >>>> most favoured media/modality/direction combination(s). A = "favoured=3Dmost" >>>> indication may be included for all media/modality/direction = combinations >>>> that are eagerly wanted together (usually one or two per = direction). If >>>> one media/modality/direction is wanted together with a most = favoured >>>> combination but with lower urgency, then the "favoured=3Dcomplement" = should >>>> be indicated (usually none or one per direction). Other >>>> media/modality/direction combinations SHALL be left without the = "favoured" >>>> indication. >>>>=20 >>>> When only one language indication for a direction in the = whole sdp >>>> is indicated, it is regarded to be the most favoured language for = the >>>> indicated direction. >>>>=20 >>>> The answering party is expected to try to start the call = in the >>>> media/modality/direction combinations indicated with favoured = parameters >>>> in the languages highest preferred by the offering party. What the >>>> answering party does if no match is possible for the highest = favoured >>>> combinations, or if no combinations are marked as highest favoured = is >>>> application dependent, and depending on the = "humintlang-disposition" >>>> session level attribute. Answering parties may select other than = the >>>> highest favoured combinations of the offer or add an interpreting = agent, >>>> e.g. a relay service to arrange for a better match in languages and >>>> modalities in the call. The media/modalities/directions/languages = selected >>>> for language communication by the answering party shall be = indicated by >>>> "humintlang-send" and "humintlang-recv" attributes in the answer. = If no >>>> match is possible, the value of the "humintlang-disposition" = session level >>>> attribute should be interrogated by the answering party for the = decision >>>> about how to handle the call. If the value is "reject", then the = call MAY >>>> be rejected. There may however be application reasons to connect = the call >>>> anyway. In that case the the humintlang-send actually intended to = be used >>>> and the humintlang-recv value of the most likely combination to be >>>> initially used in the call shoud be included in the answer. = Emergency >>>> calls should not be rejected because of language mismatch reasons. = The >>>> mechanism provides a "favoured" modality parameter that MAY be = included in >>>> the "humintlang-send" and "humintlang-recv" attribute values on = media >>>> level. The "favoured" modality parameter is a keyword parameter = with the >>>> name "favoured" and values "most" and "complement". >>>>=20 >>>> This parameter is intended to be optionally included once = for each >>>> combination of media, modality and direction of language. The = indication >>>> is intended to carry the information that the indicated = combination is >>>> the highest favoured alternative if the value is "most", and is a = highly >>>> favoured complement to the most favoured modality in another media >>>> description if the value is "complement". The value "most" is = allowed for >>>> more than one media/modality/direction combination for cases when = it is >>>> essential for the indicating party to use more than one modality in = the >>>> same direction. The "complement" value SHOULD not be used without = any >>>> "most" value in the sdp, and should only be used for cases when the >>>> modality it is used with is supposed to be used for language = transfer >>>> simultanously with the corresponding most favoured modality. >>>>=20 >>>> The offering party is expected to include all supported = languages >>>> in the offer. The answering party who can match sufficient >>>> languages/modalities and directions of the offering party, is = expected to >>>> include in the answer the languages selected for initial use in the = call >>>> and include the "favoured=3Dmost" parameter for the modalities that = the call >>>> is intended to start with. If no match was found, then all = supported >>>> languages should be included and the "favoured=3Dmost" parameter = for the >>>> modalities that the call is intended to start with. >>>>=20 >>>> o Mux Category: >>>> NORMAL >>>>=20 >>>> o Reference: >>>> draft-ietf-slim-human-language-negotiation >>>>=20 >>>> o Examples: (with shortened surrounding sdp) >>>>=20 >>>> Offer: >>>> s=3D- >>>> a=3Dhumintlang-disposition: connect >>>> m=3Daudio 34056 RTP/AVP 8 >>>> a=3Dhumintlang-send: modality=3Dspoken favoured=3Dmost en fr >>>> m=3Dvideo 36068 RTP/AVP 34 >>>> m=3Dtext 35072 RTP/AVP 102 >>>> a=3Dhumintlang-recv: modality=3Dwritten favoured=3Dmost en fr >>>> a=3Dhumintlang-send: modality=3Dwritten en fr >>>>=20 >>>> Answer >>>> s=3D- >>>> a=3Dhumintlang-disposition: connect >>>> m=3Daudio 34066 RTP/AVP 8 >>>> a=3Dhumintlang-recv: modality=3Dspoken favoured=3Dmost en >>>> m=3Dvideo 0 RTP/AVP 34 >>>> m=3Dtext 35092 RTP/AVP 102 >>>> a=3Dhumintlang-send: modality=3Dwritten favoured=3Dmost en >>>>=20 >>>>=20 >>>> This sdp exchange indicates that the offering party wants the call = to be >>>> connected regardless of the outcome of the negotiation, and that = the most >>>> favoured modality and language is to speak English, but speaking = French is >>>> also possible. >>>> The offering party also offers video, but with no intention to use = it for >>>> language. >>>> The incoming language is preferred in written real-time text form. >>>> The offering party can accept to send English or French text if the = other >>>> party is not capable of receiving spoken English. >>>>=20 >>>> The answering party accepts to connect the call, and use the = favoured >>>> modalities in English. No video capability is available, so the = video >>>> offer is rejected, but the call connected, and the answering party = can >>>> start with a written text greeting and expect to get spoken = response. >>>>=20 >>>> Note: Both the humintlang-disposition value "connect" and the = modalities >>>> indicated are the default values, so they could in this case have = been >>>> left out with the same result. >>>>=20 >>>> -- >>>> = -------------------------------------+------------------------------------= - >>>> Reporter: | Owner: draft-ietf-slim- >>>> gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: negotiating-human- | Version: >>>> language | Keywords: Attribute >>>> Severity: - | >>>> = -------------------------------------+------------------------------------= - >>>>=20 >>>> Ticket URL: >>>> slim >>>>=20 >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>=20 >> -- >> ----------------------------------------- >> Gunnar Hellstr=C3=B6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > It has been observed that one's nose is never so happy as when > it is thrust into the affairs of another, from which some > physiologists have drawn the inference that the nose is devoid > of the sense of smell. > --Ambrose Bierce, "The Devil's Dictionary" From nobody Fri Aug 12 14:14:45 2016 Return-Path: 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 429F912D532 for ; Fri, 12 Aug 2016 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=unavailable 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 2144KK8mylEb for ; Fri, 12 Aug 2016 14:14:40 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 7425B12D12E for ; Fri, 12 Aug 2016 14:14:39 -0700 (PDT) X-Halon-ID: c3b2fd51-60d1-11e6-b845-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 12 Aug 2016 23:14:32 +0200 (CEST) To: Randall Gellens , Brian Rosen , slim issue tracker References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 12 Aug 2016 23:14:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 21:14:44 -0000 Den 2016-08-12 kl. 22:14, skrev Randall Gellens: > Hi Gunnar, > > These create a complex mechanism that goes beyond what we agreed to do > for the initial version. I'm happy to work with you on these > mechanisms or something else for a revision or extension. Randy, can you please be explicit per change proposal. They are not really complex mechanisms. They are merely more explicit indications. Some of the proposed changes are simply efforts to get what the draft want to say into an acceptable logic format. There may of course be better ways to express them. There are some additions that could be sacrificed if we need to. ( e.g. the "improve" value of the humintlang-disposition), while the rest is needed to create some usability of the indications. ( have you tried yourself to go through an imagined offer-answer scenario with a multimedia call? You will discover that the situation is underspecified and will not give any of the guidance talked about in the introduction if you just use the indications from version -04, while by accepting most of the proposed changes, you will be better off for the most often appearing cases.) Thanks Gunnar > > --Randy > > At 9:33 PM +0200 8/12/16, Gunnar Hellström wrote: > >> Den 2016-08-09 kl. 15:06, skrev Brian Rosen: >>> I agree that we need to conform to the 4566 template. >>> >>> I don't agree with changing the definition of the attribute. >> I find it hard to see that you do not agree in any of the proposed >> changes in the definitions. >> Here they are in a numbered list. >> >> 1. Move the session level parameter about rejecting or connecting >> the call in case of no language match to session level. There is no >> logically correct place for this parameter in the media level >> attributes. >> >> 2. Revert the default value of the rejecting or connecting the call >> at no match to be connecting. That matches the scope of the parameter >> better, and is in line with the discussion in the mail list. >> >> 3. Add a value "improve" to the session level attribute, with the >> meaning "I can improve language matches by introduction of means not >> initially indicated. ( such as a caller not invoking a relay service >> initially, but after the answer when it shows that a relay service is >> needed. ) >> >> 4. Introduce a modality parameter in the humintlang-send and >> humintlang-recv attribute values. Default values handle most cases, >> but there are cases when an explicit value is needed, because it is >> not evident from the m-line and the language tag what modality >> indicated. This is especially true for m=application cases. >> (A complex alternative would be to specify all cases we know now >> explicitly of language use where it is not explicit by the mime type >> and the language tag what modality is intended, but I think that is >> too inflexible. ) >> >> 5. Combine all languages for one media, modality and direction in a >> space separated list as value to one humintlang-send or >> humintlang-recv attribute. That matches the format of the SIP >> Accept-Language field value. >> It also matches the logic of only indicating one highest favoured >> language. >> It would be possible to have only one language per humintlang-send >> or humintlang-recv attribute and include multiple attributes per >> media and direction. But then the syntax of the most favoured >> parameter gets less logical. Therefore I propose the changed >> attribute syntax. >> >> 6. Introduce a mark for most favoured media, meaning that the first >> language in the value list of the corresponding attribute is the most >> favoured for that direction. This can enable the negotiation to >> result in good decisions so that language exchange gets efficient. >> Without it, the start of the call will be in randomly selected >> modality and language among a set with undefined relative favour, >> causing problems to correct the modality and language when it gets >> initially wrong. >> >> 7. Allow indication of up to two highest favoured modalities per >> direction, or one highest favoured and one complementing, so that >> good decisions can be made. >> That enables specifying the needs behind the use of some common >> types of relay services or favoured behavior of the other party. >> Without this, there are calls that will not be answered in the most >> efficient way, instead causing confusion and delay. >> >> >> Regards >> >> Gunnar >> >> >> >>> >>> Brian >>> >>> >>>> On Aug 9, 2016, at 4:49 AM, slim issue tracker >>>> wrote: >>>> >>>> #9: Attribute specifications following the layout required by >>>> RFC4566bis >>>> >>>> The attribute specifications need to be more formal than in the >>>> current >>>> draft (-04 ) >>>> >>>> The following is required from attribute specifications according >>>> to RFC >>>> 4566bis, section 8.2.4.1: >>>> >>>> >>>> >>>> "New attribute registrations are accepted according to the >>>> "Specification Required" policy of [RFC5226], provided that the >>>> specification includes the following information: >>>> >>>> o Contact Name. >>>> >>>> o Contact Email Address. >>>> >>>> o Attribute Name: The name of the attribute that will appear in >>>> SDP). This MUST conform to the definition of . >>>> >>>> o Attribute Syntax: For a value attribute (see clause 5.13), >>>> an ABNF >>>> definition of the attribute value syntax (See >>>> Section Section 9) MUST be provided. The syntax MUST >>>> follow the >>>> rule form as per Section 2.2 of [RFC5234]. This SHALL >>>> define the >>>> allowable values that the attribute might take. It MAY also >>>> define an extension method for the addition of future >>>> values. For >>>> a property attribute, the ABNF definition is omitted as the >>>> property attribute takes no values. >>>> >>>> o Attribute Semantics: For a value attribute, a semantic >>>> description >>>> of the values that the attribute might take MUST be >>>> provided. The >>>> usage of a property attribute is described under purpose >>>> below. >>>> >>>> o Attribute Value: The name of an ABNF syntax rule defining the >>>> syntax of the value. Absence of a rule name indicates that >>>> the >>>> attribute takes no values. Enclosing the rule name in "[" >>>> and "]" >>>> indicates that a value is optional. >>>> >>>> o Usage Level: Usage level(s) of the attribute. One or more of: >>>> session, media, source, dcsa, dcsa(subprotocol). For a >>>> definition >>>> of source level attributes, see [RFC5576]. For a >>>> definition of >>>> dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. >>>> >>>> o Charset Dependent: Whether the attribute value is subject >>>> to the >>>> charset attribute or not (Yes/No). >>>> >>>> o Purpose: An explanation of the purpose and usage of the >>>> attribute. >>>> >>>> o O/A Procedures: Offer/Answer procedures as explained in >>>> [RFC3264]. >>>> >>>> o Mux Category: Indication of which multiplexing "category" >>>> [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is >>>> associated >>>> with. >>>> >>>> o Reference: A reference to the specification defining the >>>> attribute. >>>> " >>>> >>>> >>>> --------------------------------------------------------------- >>>> Change. Add chapters on the attributes in the format described in >>>> RFC4566bis, section 8.2.4.1 >>>> >>>> Some changes are also needed in the earlier text in the draft to >>>> align >>>> with these attribute specifications. >>>> -------------------------------------------------------------------- >>>> >>>> >>>> x. Specification of the "humintlang-disposition" attribute >>>> >>>> o Contact Name. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>> >>>> o Contact Email Address. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>> >>>> o Attribute Name: >>>> humintlang-disposition >>>> >>>> o Attribute Syntax: >>>> humintlang-disposition = "a=humintlang-disposition" HCOLON >>>> disposition >>>> >>>> o Attribute Semantics: >>>> If no match is possible, the value of the >>>> "humintlang-disposition" >>>> session level attribute should be interrogated by the answering >>>> party for >>>> the decision about how to handle the call. If the value is >>>> "reject", then >>>> the call MAY be rejected. There may however be application reasons to >>>> connect the call anyway. In that case the the humintlang-send >>>> actually >>>> intended to be used and the humintlang-recv value of the most likely >>>> combination to be initially used in the call shoud be included in the >>>> answer. Emergency calls should not be rejected because of language >>>> mismatch reasons. >>>> >>>> If the value of the "humintlang-disposition" session level >>>> attribute is "improve", then the party who inserted that value has >>>> some >>>> means to improve the match e.g. by adding an interpreting agent, >>>> e.g. a >>>> relay service. An answering party detecting the "improve" value >>>> may then >>>> connect the call, insert all its non-matching humintlang-send and >>>> humintlang-recv values and look forward to receiving new sdp with >>>> possibly >>>> better match. The offering party, or a service provider along the >>>> call >>>> path, detecting in the answer that the >>>> media/modality/direction/language >>>> indications did not match, may act to improve the match, e.g. by >>>> adding an >>>> interpreting agent, e.g. a relay service, to arrange for a better >>>> match. >>>> The parties involved in the call shall be informed about the >>>> result of >>>> such actions by new sdp with new values in the humintlang >>>> attributes. The >>>> mechanisms for such detection, decision and modifications of the >>>> call are >>>> out of scope for this specification. The ability to use such >>>> mechanisms >>>> shall be indicated by the value "improve" in the >>>> "humintlang-disposition" >>>> session attribute. >>>> >>>> When the value of the "humintlang-disposition" is >>>> "connect" (that >>>> is also the default value), then the call should be connected even >>>> without >>>> matching language/modality/direction indications. In that case the >>>> the >>>> humintlang-send actually intended to be used and the >>>> humintlang-recv value >>>> of the most likely combination to be initially used in the call >>>> shoud be >>>> included in the answer. The connected parties may use in-band >>>> actions to >>>> figure out if they have any human language communication means >>>> that fulfil >>>> the intentions of the call. >>>> >>>> o Attribute Value: >>>> disposition = "reject"/"complete"/"improve"/disposition-extension >>>> disposition-extension = token >>>> The value "complete" is default. >>>> >>>> o Usage Level: >>>> session >>>> >>>> o Charset Dependent: No. >>>> >>>> o Purpose: >>>> The attribute specifies how to handle the call when no >>>> language or >>>> modality match is found. >>>> >>>> >>>> o O/A Procedures: >>>> If no match is possible, the value of the >>>> "humintlang-disposition" >>>> session level attribute should be interrogated by the answering >>>> party for >>>> the decision about how to handle the call. If the value is >>>> "reject", then >>>> the call MAY be rejected. There may however be application reasons to >>>> connect the call anyway. In that case the the humintlang-send >>>> actually >>>> intended to be used and the humintlang-recv value of the most likely >>>> combination to be initially used in the call shoud be included in the >>>> answer. Emergency calls should not be rejected because of language >>>> mismatch reasons. >>>> >>>> An answering party detecting the "improve" value may then >>>> connect >>>> the call, insert all its non-matching humintlang-send and >>>> humintlang-recv >>>> values and look forward to receiving new sdp with possibly better >>>> match. >>>> The offering party, or a service provider along the call path, >>>> detecting >>>> in the answer that the media/modality/direction/language >>>> indications did >>>> not match, may act to improve the match, e.g. by adding an >>>> interpreting >>>> agent, e.g. a relay service, to arrange for a better match. The >>>> parties >>>> involved in the call shall be informed about the result of such >>>> actions by >>>> new sdp with new values in the humintlang attributes. >>>> >>>> When the value of the "humintlang-disposition" is >>>> "connect" (that >>>> is also the default value), then the call should be connected even >>>> without >>>> matching language/modality/direction indications. In that case the >>>> the >>>> humintlang-send actually intended to be used and the >>>> humintlang-recv value >>>> of the most likely combination to be initially used in the call >>>> shoud be >>>> included in the answer. >>>> >>>> o Mux Category: >>>> NORMAL >>>> >>>> o Reference: >>>> >>>> draft-ietf-slim-human-language-negotiation >>>> >>>> o Example: >>>> See the example for the humintlang-send and humintlang-recv >>>> attributes. >>>> >>>> >>>> >>>> Y. Specification of the humintlang-send and humintlang-recv >>>> attributes >>>> >>>> o Contact Name. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>> >>>> o Contact Email Address. >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>> >>>> o Attribute Name: >>>> humintlang-recv >>>> >>>> humintlang-send >>>> >>>> >>>> >>>> o Attribute Syntax: >>>> humintlang-send = "a=humintlang-send" HCOLON >>>> [humintlang-value] >>>> >>>> humintlang-recv = "a=humintlang-recv" HCOLON >>>> [humintlang-value] >>>> >>>> When used without language parameter, the humintlang-send >>>> and >>>> humntlang-recv attribute indicates modality and direction for use >>>> with the >>>> default language of the area and media or media/subprotocol. >>>> >>>> >>>> o Attribute Semantics: >>>> In order to successfully start a call, the parties need to be >>>> aware of >>>> which language capabilities were negotiated, and also which >>>> modality the >>>> parties prefer to use. A call can start without hesitation and be >>>> conducted smoothly only when answered with the modality and >>>> language that >>>> best matches the most favoured combinations by the caller. There is a >>>> tendency among call participants to continue using the modality >>>> first used >>>> in a call, even if that is not the most favoured modality. The call >>>> participants usually want to communicate about the topic of the >>>> call, and >>>> not about how the call will be performed. Therefore, a mechanism is >>>> provided for indication of most preferred modality/modalities of >>>> the call >>>> participants together with the language attributes. >>>> >>>> The humintlang-send attribute indicates modality and >>>> language >>>> preferences for transmission from the indicating party. >>>> The humintlang-recv attribute indicates modality and >>>> language >>>> preferences for reception by the indicating party. >>>> >>>> The mechanism provides a "favoured" modality parameter >>>> that MAY be >>>> included in the "humintlang-send" and "humintlang-recv" attribute >>>> values >>>> on media level. The "favoured" modality parameter is a keyword >>>> parameter >>>> with the name "favoured" and values "most" and "complement". >>>> >>>> The "favoured" parameter is intended to be optionally >>>> included >>>> once for each combination of media, modality and direction of >>>> language. >>>> The indication is intended to carry the information that the >>>> indicated >>>> combination is the highest favoured alternative if the value is >>>> "most", >>>> and is a highly favoured complement to the most favoured modality in >>>> another media description if the value is "complement". The value >>>> "most" >>>> is allowed for more than one media/modality/direction combination for >>>> cases when it is essential for the indicating party to use more >>>> than one >>>> modality in the same direction. The "complement" value SHOULD not >>>> be used >>>> without any "most" value in the sdp, and should only be used for >>>> cases >>>> when the modality it is used with is supposed to be used for language >>>> transfer simultanously with the corresponding most favoured modality. >>>> >>>> The language parameter is an optional list of languages >>>> that the >>>> indicating party is prepared to use in the indicated media, >>>> modality and >>>> direction. The list is a whitespace separated list of language tags >>>> arranged in preference order, with highest preferred first. >>>> >>>> >>>> o Attribute Value: >>>> >>>> humintlang-value =[*humintlang-param][*language] >>>> humintlang-param = [modality][favoured] >>>> modality = "modality=" >>>> ("spoken"/"signed"/"written"/modality- >>>> extension) >>>> The value "spoken" is default for audio media. >>>> The value "signed" is default for video media except when >>>> used >>>> with a spoken or written language. >>>> The value "spoken" is default for video media when used with >>>> spoken language. >>>> The value "written" is default for text media >>>> favoured= "favoured="("most"/"complement") >>>> modality-extension = token >>>> Modalities can be extended with further modalities and >>>> assigned >>>> values indicated >>>> language = Language-Tag >>>> where Language-Tag is defined in RFC 5646, Section 2.1. >>>> >>>> >>>> o Usage Level: >>>> media, dcsa(subprotocol). >>>> dcsa(T140) can be indicated to carry text modality. >>>> >>>> o Charset Dependent: No >>>> >>>> o Purpose: >>>> In order to successfully start a call, the parties need to be >>>> aware of >>>> which language capabilities were negotiated, and also which >>>> modality the >>>> parties prefer to use. A call can start without hesitation and be >>>> conducted smoothly only when answered with the modality and >>>> language that >>>> best matches the most favoured combinations by the caller. The >>>> attributes >>>> are intended to carry the information about supported and favoured >>>> languages and modalities between the communicating parties. >>>> >>>> o O/A Procedures: >>>> Offering parties who strongly favour specific ways to >>>> communicate >>>> by language are expected to indicate these ways using the >>>> humintlang-send >>>> or humintlang-recv attributes with the "favoured=most" parameter >>>> on the >>>> most favoured media/modality/direction combination(s). A >>>> "favoured=most" >>>> indication may be included for all media/modality/direction >>>> combinations >>>> that are eagerly wanted together (usually one or two per >>>> direction). If >>>> one media/modality/direction is wanted together with a most favoured >>>> combination but with lower urgency, then the "favoured=complement" >>>> should >>>> be indicated (usually none or one per direction). Other >>>> media/modality/direction combinations SHALL be left without the >>>> "favoured" >>>> indication. >>>> >>>> When only one language indication for a direction in the >>>> whole sdp >>>> is indicated, it is regarded to be the most favoured language for the >>>> indicated direction. >>>> >>>> The answering party is expected to try to start the call >>>> in the >>>> media/modality/direction combinations indicated with favoured >>>> parameters >>>> in the languages highest preferred by the offering party. What the >>>> answering party does if no match is possible for the highest favoured >>>> combinations, or if no combinations are marked as highest favoured is >>>> application dependent, and depending on the "humintlang-disposition" >>>> session level attribute. Answering parties may select other than the >>>> highest favoured combinations of the offer or add an interpreting >>>> agent, >>>> e.g. a relay service to arrange for a better match in languages and >>>> modalities in the call. The media/modalities/directions/languages >>>> selected >>>> for language communication by the answering party shall be >>>> indicated by >>>> "humintlang-send" and "humintlang-recv" attributes in the answer. >>>> If no >>>> match is possible, the value of the "humintlang-disposition" >>>> session level >>>> attribute should be interrogated by the answering party for the >>>> decision >>>> about how to handle the call. If the value is "reject", then the >>>> call MAY >>>> be rejected. There may however be application reasons to connect >>>> the call >>>> anyway. In that case the the humintlang-send actually intended to >>>> be used >>>> and the humintlang-recv value of the most likely combination to be >>>> initially used in the call shoud be included in the answer. Emergency >>>> calls should not be rejected because of language mismatch >>>> reasons. The >>>> mechanism provides a "favoured" modality parameter that MAY be >>>> included in >>>> the "humintlang-send" and "humintlang-recv" attribute values on media >>>> level. The "favoured" modality parameter is a keyword parameter >>>> with the >>>> name "favoured" and values "most" and "complement". >>>> >>>> This parameter is intended to be optionally included once >>>> for each >>>> combination of media, modality and direction of language. The >>>> indication >>>> is intended to carry the information that the indicated >>>> combination is >>>> the highest favoured alternative if the value is "most", and is a >>>> highly >>>> favoured complement to the most favoured modality in another media >>>> description if the value is "complement". The value "most" is >>>> allowed for >>>> more than one media/modality/direction combination for cases when >>>> it is >>>> essential for the indicating party to use more than one modality >>>> in the >>>> same direction. The "complement" value SHOULD not be used without any >>>> "most" value in the sdp, and should only be used for cases when the >>>> modality it is used with is supposed to be used for language transfer >>>> simultanously with the corresponding most favoured modality. >>>> >>>> The offering party is expected to include all supported >>>> languages >>>> in the offer. The answering party who can match sufficient >>>> languages/modalities and directions of the offering party, is >>>> expected to >>>> include in the answer the languages selected for initial use in >>>> the call >>>> and include the "favoured=most" parameter for the modalities that >>>> the call >>>> is intended to start with. If no match was found, then all supported >>>> languages should be included and the "favoured=most" parameter for >>>> the >>>> modalities that the call is intended to start with. >>>> >>>> o Mux Category: >>>> NORMAL >>>> >>>> o Reference: >>>> draft-ietf-slim-human-language-negotiation >>>> >>>> o Examples: (with shortened surrounding sdp) >>>> >>>> Offer: >>>> s=- >>>> a=humintlang-disposition: connect >>>> m=audio 34056 RTP/AVP 8 >>>> a=humintlang-send: modality=spoken favoured=most en fr >>>> m=video 36068 RTP/AVP 34 >>>> m=text 35072 RTP/AVP 102 >>>> a=humintlang-recv: modality=written favoured=most en fr >>>> a=humintlang-send: modality=written en fr >>>> >>>> Answer >>>> s=- >>>> a=humintlang-disposition: connect >>>> m=audio 34066 RTP/AVP 8 >>>> a=humintlang-recv: modality=spoken favoured=most en >>>> m=video 0 RTP/AVP 34 >>>> m=text 35092 RTP/AVP 102 >>>> a=humintlang-send: modality=written favoured=most en >>>> >>>> >>>> This sdp exchange indicates that the offering party wants the call >>>> to be >>>> connected regardless of the outcome of the negotiation, and that >>>> the most >>>> favoured modality and language is to speak English, but speaking >>>> French is >>>> also possible. >>>> The offering party also offers video, but with no intention to use >>>> it for >>>> language. >>>> The incoming language is preferred in written real-time text form. >>>> The offering party can accept to send English or French text if >>>> the other >>>> party is not capable of receiving spoken English. >>>> >>>> The answering party accepts to connect the call, and use the favoured >>>> modalities in English. No video capability is available, so the video >>>> offer is rejected, but the call connected, and the answering party >>>> can >>>> start with a written text greeting and expect to get spoken response. >>>> >>>> Note: Both the humintlang-disposition value "connect" and the >>>> modalities >>>> indicated are the default values, so they could in this case have >>>> been >>>> left out with the same result. >>>> >>>> -- >>>> -------------------------------------+------------------------------------- >>>> >>>> Reporter: | Owner: draft-ietf-slim- >>>> gunnar.hellstrom@omnitor.se | >>>> negotiating-human-language@ietf.org >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: negotiating-human- | Version: >>>> language | Keywords: Attribute >>>> Severity: - | >>>> -------------------------------------+------------------------------------- >>>> >>>> >>>> Ticket URL: >>>> slim >>>> >>>> _______________________________________________ >>>> 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 > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Fri Aug 12 14:25:03 2016 Return-Path: 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 E837212B03A for ; Fri, 12 Aug 2016 14:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 i30QmhexUYaA for ; Fri, 12 Aug 2016 14:24:59 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 3FE7A128874 for ; Fri, 12 Aug 2016 14:24:58 -0700 (PDT) X-Halon-ID: 35cd571f-60d3-11e6-b845-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 12 Aug 2016 23:24:53 +0200 (CEST) To: slim@ietf.org References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 12 Aug 2016 23:24:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 21:25:02 -0000 Den 2016-08-12 kl. 22:58, skrev Brian Rosen: > I agree. Some detail below Thanks Brian for being explicit. I hope we can get good opportunities to discuss the points one by one. One point that amazed me was that you did not want the modality parameter. How do you then propose to know where to find e.g. the written modality in an WebRTC sdp? Thanks, Gunnar >> On Aug 12, 2016, at 4:14 PM, Randall Gellens wrote: >> >> Hi Gunnar, >> >> These create a complex mechanism that goes beyond >> what we agreed to do for the initial version. >> I'm happy to work with you on these mechanisms or >> something else for a revision or extension. >> >> --Randy >> >> At 9:33 PM +0200 8/12/16, Gunnar Hellström wrote: >> >>> Den 2016-08-09 kl. 15:06, skrev Brian Rosen: >>>> I agree that we need to conform to the 4566 template. >>>> >>>> I don't agree with changing the definition of the attribute. >>> I find it hard to see that you do not agree in >>> any of the proposed changes in the definitions. >>> Here they are in a numbered list. >>> >>> 1. Move the session level parameter about >>> rejecting or connecting the call in case of no >>> language match to session level. There is no >>> logically correct place for this parameter in >>> the media level attributes. > I’m not worried about having this be at a media level. The recipient can always reject the call for whatever reason it wants. The sender can always drop the call if it doesn’t like the result of negotiations. t could easily construct use cases where what you want is media decisions, not session decisions (so, if you can’t give me English text, I don’t care if you can give me Spanish video, I want to fail the call). It’s all advisory, and I’d prefer to keep it where it is. > >>> 2. Revert the default value of the rejecting or >>> connecting the call at no match to be >>> connecting. That matches the scope of the >>> parameter better, and is in line with the >>> discussion in the mail list. > I don’t really care about this. Again, this is at best advisory, and either end can reject any time. If you rely on defaults to get what you want, you deserve what you get. > >>> 3. Add a value "improve" to the session level >>> attribute, with the meaning "I can improve >>> language matches by introduction of means not >>> initially indicated. ( such as a caller not >>> invoking a relay service initially, but after >>> the answer when it shows that a relay service >>> is needed. ) > I am strongly against doing this ever. If you need to renegotiate, drop the call and try again, probably with some different path (i.e. with relay). > >>> 4. Introduce a modality parameter in the >>> humintlang-send and humintlang-recv attribute >>> values. Default values handle most cases, but >>> there are cases when an explicit value is >>> needed, because it is not evident from the >>> m-line and the language tag what modality >>> indicated. This is especially true for >>> m=application cases. >>> (A complex alternative would be to specify all >>> cases we know now explicitly of language use >>> where it is not explicit by the mime type and >>> the language tag what modality is intended, but >>> I think that is too inflexible. ) > I am strongly against doing this ever. I think it’s a bad idea. > >>> 5. Combine all languages for one media, >>> modality and direction in a space separated >>> list as value to one humintlang-send or >>> humintlang-recv attribute. That matches the >>> format of the SIP Accept-Language field value. >>> It also matches the logic of only indicating one highest favoured language. >>> It would be possible to have only one language >>> per humintlang-send or humintlang-recv >>> attribute and include multiple attributes per >>> media and direction. But then the syntax of the >>> most favoured parameter gets less logical. >>> Therefore I propose the changed attribute >>> syntax. > I am strongly against doing this at this time. I’m not sure if makes any sense, and I’d like to get some experience before we make decisions in this area. > >>> 6. Introduce a mark for most favoured media, >>> meaning that the first language in the value >>> list of the corresponding attribute is the most >>> favoured for that direction. This can enable >>> the negotiation to result in good decisions so >>> that language exchange gets efficient. Without >>> it, the start of the call will be in randomly >>> selected modality and language among a set with >>> undefined relative favour, causing problems to >>> correct the modality and language when it gets >>> initially wrong. > I really don’t think this is the best way to handle interactions between media, but regardless, at this time, I don’t think we should have mechanisms like this. > >>> 7. Allow indication of up to two highest >>> favoured modalities per direction, or one >>> highest favoured and one complementing, so that >>> good decisions can be made. >>> That enables specifying the needs behind the >>> use of some common types of relay services or >>> favoured behavior of the other party. Without >>> this, there are calls that will not be answered >>> in the most efficient way, instead causing >>> confusion and delay. > I am strongly against doing this at this time. I doubt this will ever be the right answer, but at least now, I we had consensus not to have mechanisms like this in the document. > >>> >>> Regards >>> >>> Gunnar >>> >>> >>> >>>> Brian >>>> >>>> >>>>> On Aug 9, 2016, at 4:49 AM, slim issue >>>>> tracker wrote: >>>>> >>>>> #9: Attribute specifications following the layout required by RFC4566bis >>>>> >>>>> The attribute specifications need to be more formal than in the current >>>>> draft (-04 ) >>>>> >>>>> The following is required from attribute specifications according to RFC >>>>> 4566bis, section 8.2.4.1: >>>>> >>>>> >>>>> >>>>> "New attribute registrations are accepted according to the >>>>> "Specification Required" policy of [RFC5226], provided that the >>>>> specification includes the following information: >>>>> >>>>> o Contact Name. >>>>> >>>>> o Contact Email Address. >>>>> >>>>> o Attribute Name: The name of the attribute that will appear in >>>>> SDP). This MUST conform to the definition of . >>>>> >>>>> o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF >>>>> definition of the attribute value syntax (See >>>>> Section Section 9) MUST be provided. The syntax MUST follow the >>>>> rule form as per Section 2.2 of [RFC5234]. This SHALL define the >>>>> allowable values that the attribute might take. It MAY also >>>>> define an extension method for the addition of future values. For >>>>> a property attribute, the ABNF definition is omitted as the >>>>> property attribute takes no values. >>>>> >>>>> o Attribute Semantics: For a value attribute, a semantic description >>>>> of the values that the attribute might take MUST be provided. The >>>>> usage of a property attribute is described under purpose below. >>>>> >>>>> o Attribute Value: The name of an ABNF syntax rule defining the >>>>> syntax of the value. Absence of a rule name indicates that the >>>>> attribute takes no values. Enclosing the rule name in "[" and "]" >>>>> indicates that a value is optional. >>>>> >>>>> o Usage Level: Usage level(s) of the attribute. One or more of: >>>>> session, media, source, dcsa, dcsa(subprotocol). For a definition >>>>> of source level attributes, see [RFC5576]. For a definition of >>>>> dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. >>>>> >>>>> o Charset Dependent: Whether the attribute value is subject to the >>>>> charset attribute or not (Yes/No). >>>>> >>>>> o Purpose: An explanation of the purpose and usage of the attribute. >>>>> >>>>> o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. >>>>> >>>>> o Mux Category: Indication of which multiplexing "category" >>>>> [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated >>>>> with. >>>>> >>>>> o Reference: A reference to the specification defining the >>>>> attribute. >>>>> " >>>>> >>>>> >>>>> --------------------------------------------------------------- >>>>> Change. Add chapters on the attributes in the format described in >>>>> RFC4566bis, section 8.2.4.1 >>>>> >>>>> Some changes are also needed in the earlier text in the draft to align >>>>> with these attribute specifications. >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>>> x. Specification of the "humintlang-disposition" attribute >>>>> >>>>> o Contact Name. >>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>> >>>>> o Contact Email Address. >>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>> >>>>> o Attribute Name: >>>>> humintlang-disposition >>>>> >>>>> o Attribute Syntax: >>>>> humintlang-disposition = "a=humintlang-disposition" HCOLON disposition >>>>> >>>>> o Attribute Semantics: >>>>> If no match is possible, the value of the "humintlang-disposition" >>>>> session level attribute should be interrogated by the answering party for >>>>> the decision about how to handle the call. If the value is "reject", then >>>>> the call MAY be rejected. There may however be application reasons to >>>>> connect the call anyway. In that case the the humintlang-send actually >>>>> intended to be used and the humintlang-recv value of the most likely >>>>> combination to be initially used in the call shoud be included in the >>>>> answer. Emergency calls should not be rejected because of language >>>>> mismatch reasons. >>>>> >>>>> If the value of the "humintlang-disposition" session level >>>>> attribute is "improve", then the party who inserted that value has some >>>>> means to improve the match e.g. by adding an interpreting agent, e.g. a >>>>> relay service. An answering party detecting the "improve" value may then >>>>> connect the call, insert all its non-matching humintlang-send and >>>>> humintlang-recv values and look forward to receiving new sdp with possibly >>>>> better match. The offering party, or a service provider along the call >>>>> path, detecting in the answer that the media/modality/direction/language >>>>> indications did not match, may act to improve the match, e.g. by adding an >>>>> interpreting agent, e.g. a relay service, to arrange for a better match. >>>>> The parties involved in the call shall be informed about the result of >>>>> such actions by new sdp with new values in the humintlang attributes. The >>>>> mechanisms for such detection, decision and modifications of the call are >>>>> out of scope for this specification. The ability to use such mechanisms >>>>> shall be indicated by the value "improve" in the "humintlang-disposition" >>>>> session attribute. >>>>> >>>>> When the value of the "humintlang-disposition" is "connect" (that >>>>> is also the default value), then the call should be connected even without >>>>> matching language/modality/direction indications. In that case the the >>>>> humintlang-send actually intended to be used and the humintlang-recv value >>>>> of the most likely combination to be initially used in the call shoud be >>>>> included in the answer. The connected parties may use in-band actions to >>>>> figure out if they have any human language communication means that fulfil >>>>> the intentions of the call. >>>>> >>>>> o Attribute Value: >>>>> disposition = "reject"/"complete"/"improve"/disposition-extension >>>>> disposition-extension = token >>>>> The value "complete" is default. >>>>> >>>>> o Usage Level: >>>>> session >>>>> >>>>> o Charset Dependent: No. >>>>> >>>>> o Purpose: >>>>> The attribute specifies how to handle the call when no language or >>>>> modality match is found. >>>>> >>>>> >>>>> o O/A Procedures: >>>>> If no match is possible, the value of the "humintlang-disposition" >>>>> session level attribute should be interrogated by the answering party for >>>>> the decision about how to handle the call. If the value is "reject", then >>>>> the call MAY be rejected. There may however be application reasons to >>>>> connect the call anyway. In that case the the humintlang-send actually >>>>> intended to be used and the humintlang-recv value of the most likely >>>>> combination to be initially used in the call shoud be included in the >>>>> answer. Emergency calls should not be rejected because of language >>>>> mismatch reasons. >>>>> >>>>> An answering party detecting the "improve" value may then connect >>>>> the call, insert all its non-matching humintlang-send and humintlang-recv >>>>> values and look forward to receiving new sdp with possibly better match. >>>>> The offering party, or a service provider along the call path, detecting >>>>> in the answer that the media/modality/direction/language indications did >>>>> not match, may act to improve the match, e.g. by adding an interpreting >>>>> agent, e.g. a relay service, to arrange for a better match. The parties >>>>> involved in the call shall be informed about the result of such actions by >>>>> new sdp with new values in the humintlang attributes. >>>>> >>>>> When the value of the "humintlang-disposition" is "connect" (that >>>>> is also the default value), then the call should be connected even without >>>>> matching language/modality/direction indications. In that case the the >>>>> humintlang-send actually intended to be used and the humintlang-recv value >>>>> of the most likely combination to be initially used in the call shoud be >>>>> included in the answer. >>>>> >>>>> o Mux Category: >>>>> NORMAL >>>>> >>>>> o Reference: >>>>> >>>>> draft-ietf-slim-human-language-negotiation >>>>> >>>>> o Example: >>>>> See the example for the humintlang-send and humintlang-recv attributes. >>>>> >>>>> >>>>> >>>>> Y. Specification of the humintlang-send and humintlang-recv attributes >>>>> >>>>> o Contact Name. >>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>> >>>>> o Contact Email Address. >>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>> >>>>> o Attribute Name: >>>>> humintlang-recv >>>>> >>>>> humintlang-send >>>>> >>>>> >>>>> >>>>> o Attribute Syntax: >>>>> humintlang-send = "a=humintlang-send" HCOLON [humintlang-value] >>>>> >>>>> humintlang-recv = "a=humintlang-recv" HCOLON [humintlang-value] >>>>> >>>>> When used without language parameter, the humintlang-send and >>>>> humntlang-recv attribute indicates modality and direction for use with the >>>>> default language of the area and media or media/subprotocol. >>>>> >>>>> >>>>> o Attribute Semantics: >>>>> In order to successfully start a call, the parties need to be aware of >>>>> which language capabilities were negotiated, and also which modality the >>>>> parties prefer to use. A call can start without hesitation and be >>>>> conducted smoothly only when answered with the modality and language that >>>>> best matches the most favoured combinations by the caller. There is a >>>>> tendency among call participants to continue using the modality first used >>>>> in a call, even if that is not the most favoured modality. The call >>>>> participants usually want to communicate about the topic of the call, and >>>>> not about how the call will be performed. Therefore, a mechanism is >>>>> provided for indication of most preferred modality/modalities of the call >>>>> participants together with the language attributes. >>>>> >>>>> The humintlang-send attribute indicates modality and language >>>>> preferences for transmission from the indicating party. >>>>> The humintlang-recv attribute indicates modality and language >>>>> preferences for reception by the indicating party. >>>>> >>>>> The mechanism provides a "favoured" modality parameter that MAY be >>>>> included in the "humintlang-send" and "humintlang-recv" attribute values >>>>> on media level. The "favoured" modality parameter is a keyword parameter >>>>> with the name "favoured" and values "most" and "complement". >>>>> >>>>> The "favoured" parameter is intended to be optionally included >>>>> once for each combination of media, modality and direction of language. >>>>> The indication is intended to carry the information that the indicated >>>>> combination is the highest favoured alternative if the value is "most", >>>>> and is a highly favoured complement to the most favoured modality in >>>>> another media description if the value is "complement". The value "most" >>>>> is allowed for more than one media/modality/direction combination for >>>>> cases when it is essential for the indicating party to use more than one >>>>> modality in the same direction. The "complement" value SHOULD not be used >>>>> without any "most" value in the sdp, and should only be used for cases >>>>> when the modality it is used with is supposed to be used for language >>>>> transfer simultanously with the corresponding most favoured modality. >>>>> >>>>> The language parameter is an optional list of languages that the >>>>> indicating party is prepared to use in the indicated media, modality and >>>>> direction. The list is a whitespace separated list of language tags >>>>> arranged in preference order, with highest preferred first. >>>>> >>>>> >>>>> o Attribute Value: >>>>> >>>>> humintlang-value =[*humintlang-param][*language] >>>>> humintlang-param = [modality][favoured] >>>>> modality = "modality=" ("spoken"/"signed"/"written"/modality- >>>>> extension) >>>>> The value "spoken" is default for audio media. >>>>> The value "signed" is default for video media except when used >>>>> with a spoken or written language. >>>>> The value "spoken" is default for video media when used with >>>>> spoken language. >>>>> The value "written" is default for text media >>>>> favoured= "favoured="("most"/"complement") >>>>> modality-extension = token >>>>> Modalities can be extended with further modalities and assigned >>>>> values indicated >>>>> language = Language-Tag >>>>> where Language-Tag is defined in RFC 5646, Section 2.1. >>>>> >>>>> >>>>> o Usage Level: >>>>> media, dcsa(subprotocol). >>>>> dcsa(T140) can be indicated to carry text modality. >>>>> >>>>> o Charset Dependent: No >>>>> >>>>> o Purpose: >>>>> In order to successfully start a call, the parties need to be aware of >>>>> which language capabilities were negotiated, and also which modality the >>>>> parties prefer to use. A call can start without hesitation and be >>>>> conducted smoothly only when answered with the modality and language that >>>>> best matches the most favoured combinations by the caller. The attributes >>>>> are intended to carry the information about supported and favoured >>>>> languages and modalities between the communicating parties. >>>>> >>>>> o O/A Procedures: >>>>> Offering parties who strongly favour specific ways to communicate >>>>> by language are expected to indicate these ways using the humintlang-send >>>>> or humintlang-recv attributes with the "favoured=most" parameter on the >>>>> most favoured media/modality/direction combination(s). A "favoured=most" >>>>> indication may be included for all media/modality/direction combinations >>>>> that are eagerly wanted together (usually one or two per direction). If >>>>> one media/modality/direction is wanted together with a most favoured >>>>> combination but with lower urgency, then the "favoured=complement" should >>>>> be indicated (usually none or one per direction). Other >>>>> media/modality/direction combinations SHALL be left without the "favoured" >>>>> indication. >>>>> >>>>> When only one language indication for a direction in the whole sdp >>>>> is indicated, it is regarded to be the most favoured language for the >>>>> indicated direction. >>>>> >>>>> The answering party is expected to try to start the call in the >>>>> media/modality/direction combinations indicated with favoured parameters >>>>> in the languages highest preferred by the offering party. What the >>>>> answering party does if no match is possible for the highest favoured >>>>> combinations, or if no combinations are marked as highest favoured is >>>>> application dependent, and depending on the "humintlang-disposition" >>>>> session level attribute. Answering parties may select other than the >>>>> highest favoured combinations of the offer or add an interpreting agent, >>>>> e.g. a relay service to arrange for a better match in languages and >>>>> modalities in the call. The media/modalities/directions/languages selected >>>>> for language communication by the answering party shall be indicated by >>>>> "humintlang-send" and "humintlang-recv" attributes in the answer. If no >>>>> match is possible, the value of the "humintlang-disposition" session level >>>>> attribute should be interrogated by the answering party for the decision >>>>> about how to handle the call. If the value is "reject", then the call MAY >>>>> be rejected. There may however be application reasons to connect the call >>>>> anyway. In that case the the humintlang-send actually intended to be used >>>>> and the humintlang-recv value of the most likely combination to be >>>>> initially used in the call shoud be included in the answer. Emergency >>>>> calls should not be rejected because of language mismatch reasons. The >>>>> mechanism provides a "favoured" modality parameter that MAY be included in >>>>> the "humintlang-send" and "humintlang-recv" attribute values on media >>>>> level. The "favoured" modality parameter is a keyword parameter with the >>>>> name "favoured" and values "most" and "complement". >>>>> >>>>> This parameter is intended to be optionally included once for each >>>>> combination of media, modality and direction of language. The indication >>>>> is intended to carry the information that the indicated combination is >>>>> the highest favoured alternative if the value is "most", and is a highly >>>>> favoured complement to the most favoured modality in another media >>>>> description if the value is "complement". The value "most" is allowed for >>>>> more than one media/modality/direction combination for cases when it is >>>>> essential for the indicating party to use more than one modality in the >>>>> same direction. The "complement" value SHOULD not be used without any >>>>> "most" value in the sdp, and should only be used for cases when the >>>>> modality it is used with is supposed to be used for language transfer >>>>> simultanously with the corresponding most favoured modality. >>>>> >>>>> The offering party is expected to include all supported languages >>>>> in the offer. The answering party who can match sufficient >>>>> languages/modalities and directions of the offering party, is expected to >>>>> include in the answer the languages selected for initial use in the call >>>>> and include the "favoured=most" parameter for the modalities that the call >>>>> is intended to start with. If no match was found, then all supported >>>>> languages should be included and the "favoured=most" parameter for the >>>>> modalities that the call is intended to start with. >>>>> >>>>> o Mux Category: >>>>> NORMAL >>>>> >>>>> o Reference: >>>>> draft-ietf-slim-human-language-negotiation >>>>> >>>>> o Examples: (with shortened surrounding sdp) >>>>> >>>>> Offer: >>>>> s=- >>>>> a=humintlang-disposition: connect >>>>> m=audio 34056 RTP/AVP 8 >>>>> a=humintlang-send: modality=spoken favoured=most en fr >>>>> m=video 36068 RTP/AVP 34 >>>>> m=text 35072 RTP/AVP 102 >>>>> a=humintlang-recv: modality=written favoured=most en fr >>>>> a=humintlang-send: modality=written en fr >>>>> >>>>> Answer >>>>> s=- >>>>> a=humintlang-disposition: connect >>>>> m=audio 34066 RTP/AVP 8 >>>>> a=humintlang-recv: modality=spoken favoured=most en >>>>> m=video 0 RTP/AVP 34 >>>>> m=text 35092 RTP/AVP 102 >>>>> a=humintlang-send: modality=written favoured=most en >>>>> >>>>> >>>>> This sdp exchange indicates that the offering party wants the call to be >>>>> connected regardless of the outcome of the negotiation, and that the most >>>>> favoured modality and language is to speak English, but speaking French is >>>>> also possible. >>>>> The offering party also offers video, but with no intention to use it for >>>>> language. >>>>> The incoming language is preferred in written real-time text form. >>>>> The offering party can accept to send English or French text if the other >>>>> party is not capable of receiving spoken English. >>>>> >>>>> The answering party accepts to connect the call, and use the favoured >>>>> modalities in English. No video capability is available, so the video >>>>> offer is rejected, but the call connected, and the answering party can >>>>> start with a written text greeting and expect to get spoken response. >>>>> >>>>> Note: Both the humintlang-disposition value "connect" and the modalities >>>>> indicated are the default values, so they could in this case have been >>>>> left out with the same result. >>>>> >>>>> -- >>>>> -------------------------------------+------------------------------------- >>>>> Reporter: | Owner: draft-ietf-slim- >>>>> gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org >>>>> Type: defect | Status: new >>>>> Priority: major | Milestone: >>>>> Component: negotiating-human- | Version: >>>>> language | Keywords: Attribute >>>>> Severity: - | >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> Ticket URL: >>>>> slim >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> It has been observed that one's nose is never so happy as when >> it is thrust into the affairs of another, from which some >> physiologists have drawn the inference that the nose is devoid >> of the sense of smell. >> --Ambrose Bierce, "The Devil's Dictionary" > _______________________________________________ > 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 From nobody Fri Aug 12 14:28:44 2016 Return-Path: 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 C444612B058 for ; Fri, 12 Aug 2016 14:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 Usea923-pA2j for ; Fri, 12 Aug 2016 14:28:37 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66171128874 for ; Fri, 12 Aug 2016 14:28:37 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id f123so21344566qkd.1 for ; Fri, 12 Aug 2016 14:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Hj8hKalrPntdWgrkLXp4ytqcMHcVxiKqfG4ytm3vmpM=; b=Ljawi9ZWajwUBOxzE5fWsqz/tr70CcYfEXRM1ZCDEFIg3ZAs6Y4EYRbYw+159qN4lZ g1fED9Yk+w3DfP3d1pwgHqlanirnlHtzzApO7Cnqe5iuHc6HgZXr3MZx3eeQrb6PqmH4 f5ZmLUfDUkgK8klJrcrVwAqY23uIV+unvBHGlI/r977NWOO1K9fS1NSauPVunRFnFcI0 BHNqdOZqgQHYp5wKUioharLDgVs40PMCcDOZ+oULszfZEocmn4KKEWLRSPUQYEH8ZXTV 7uL9gvaQCHfPrZWj3pCL4D3JIWyIzHviUWMjC1gQsy5/JHUQR9jdv+zTL537r2CRO1eQ VLhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Hj8hKalrPntdWgrkLXp4ytqcMHcVxiKqfG4ytm3vmpM=; b=iq5hIzVtwcutNIUBpGjnN95Si62vcrlBJO6pC7WtRJSAMNtuqQO2xNB0CCmz6SyP7G S50NTMitPHSSMjswr4HBLtyYepXtndjjE5ITvsyupdJG9OiE6DJWqBB8m5xkn4bBJlpp rF/MK3bQwW2e4wPLgN7j0cd4zJ3LwHQC7gOMaz27OsCUfrr3ZIXOnlCpHF3rFA/1PY0s PV4LeF3fAV/AsbCug4/CFPPCxGk6nI+0ppWbr+Dpt6RmbmtU0g4sObVC9PNwFpXhdUiP Z2OpruBEC3M8g5FA6JVVtTfTdZq6TnJTNA52rSJICscEA+wVN9TUoV8fydy0eh9dlKen flBA== X-Gm-Message-State: AEkooutC8cskpafbGbyMpHTzgzNLmTYXZkZB5YNewoh7a6KV+EktkORnwtSAWN2nsWuMTw== X-Received: by 10.55.23.152 with SMTP id 24mr20981678qkx.241.1471037316358; Fri, 12 Aug 2016 14:28:36 -0700 (PDT) Received: from [10.33.193.48] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id p26sm4196373qkh.28.2016.08.12.14.28.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Aug 2016 14:28:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CFB4A8FC-1F89-4D2A-89A9-26E06E6F03DD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 12 Aug 2016 17:28:31 -0400 Message-Id: References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> <63772B78-08B1-493A-A929-3166474F2700@brianrosen.net> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 21:28:42 -0000 --Apple-Mail=_CFB4A8FC-1F89-4D2A-89A9-26E06E6F03DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am not worried about applying a language to m=3Dapplication. I = don=E2=80=99t think anyone will be confused. Brian > On Aug 12, 2016, at 5:24 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Den 2016-08-12 kl. 22:58, skrev Brian Rosen: >> I agree. Some detail below > Thanks Brian for being explicit. > I hope we can get good opportunities to discuss the points one by one. > One point that amazed me was that you did not want the modality = parameter. How do you then propose to know where to find e.g. the = written modality in an WebRTC sdp? >=20 > Thanks, > Gunnar >>> On Aug 12, 2016, at 4:14 PM, Randall Gellens = wrote: >>>=20 >>> Hi Gunnar, >>>=20 >>> These create a complex mechanism that goes beyond >>> what we agreed to do for the initial version. >>> I'm happy to work with you on these mechanisms or >>> something else for a revision or extension. >>>=20 >>> --Randy >>>=20 >>> At 9:33 PM +0200 8/12/16, Gunnar Hellstr=C3=B6m wrote: >>>=20 >>>> Den 2016-08-09 kl. 15:06, skrev Brian Rosen: >>>>> I agree that we need to conform to the 4566 template. >>>>>=20 >>>>> I don't agree with changing the definition of the attribute. >>>> I find it hard to see that you do not agree in >>>> any of the proposed changes in the definitions. >>>> Here they are in a numbered list. >>>>=20 >>>> 1. Move the session level parameter about >>>> rejecting or connecting the call in case of no >>>> language match to session level. There is no >>>> logically correct place for this parameter in >>>> the media level attributes. >> I=E2=80=99m not worried about having this be at a media level. The = recipient can always reject the call for whatever reason it wants. The = sender can always drop the call if it doesn=E2=80=99t like the result of = negotiations. t could easily construct use cases where what you want is = media decisions, not session decisions (so, if you can=E2=80=99t give me = English text, I don=E2=80=99t care if you can give me Spanish video, I = want to fail the call). It=E2=80=99s all advisory, and I=E2=80=99d = prefer to keep it where it is. >>=20 >>>> 2. Revert the default value of the rejecting or >>>> connecting the call at no match to be >>>> connecting. That matches the scope of the >>>> parameter better, and is in line with the >>>> discussion in the mail list. >> I don=E2=80=99t really care about this. Again, this is at best = advisory, and either end can reject any time. If you rely on defaults = to get what you want, you deserve what you get. >>=20 >>>> 3. Add a value "improve" to the session level >>>> attribute, with the meaning "I can improve >>>> language matches by introduction of means not >>>> initially indicated. ( such as a caller not >>>> invoking a relay service initially, but after >>>> the answer when it shows that a relay service >>>> is needed. ) >> I am strongly against doing this ever. If you need to renegotiate, = drop the call and try again, probably with some different path (i.e. = with relay). >>=20 >>>> 4. Introduce a modality parameter in the >>>> humintlang-send and humintlang-recv attribute >>>> values. Default values handle most cases, but >>>> there are cases when an explicit value is >>>> needed, because it is not evident from the >>>> m-line and the language tag what modality >>>> indicated. This is especially true for >>>> m=3Dapplication cases. >>>> (A complex alternative would be to specify all >>>> cases we know now explicitly of language use >>>> where it is not explicit by the mime type and >>>> the language tag what modality is intended, but >>>> I think that is too inflexible. ) >> I am strongly against doing this ever. I think it=E2=80=99s a bad = idea. >>=20 >>>> 5. Combine all languages for one media, >>>> modality and direction in a space separated >>>> list as value to one humintlang-send or >>>> humintlang-recv attribute. That matches the >>>> format of the SIP Accept-Language field value. >>>> It also matches the logic of only indicating one highest favoured = language. >>>> It would be possible to have only one language >>>> per humintlang-send or humintlang-recv >>>> attribute and include multiple attributes per >>>> media and direction. But then the syntax of the >>>> most favoured parameter gets less logical. >>>> Therefore I propose the changed attribute >>>> syntax. >> I am strongly against doing this at this time. I=E2=80=99m not sure = if makes any sense, and I=E2=80=99d like to get some experience before = we make decisions in this area. >>=20 >>>> 6. Introduce a mark for most favoured media, >>>> meaning that the first language in the value >>>> list of the corresponding attribute is the most >>>> favoured for that direction. This can enable >>>> the negotiation to result in good decisions so >>>> that language exchange gets efficient. Without >>>> it, the start of the call will be in randomly >>>> selected modality and language among a set with >>>> undefined relative favour, causing problems to >>>> correct the modality and language when it gets >>>> initially wrong. >> I really don=E2=80=99t think this is the best way to handle = interactions between media, but regardless, at this time, I don=E2=80=99t = think we should have mechanisms like this. >>=20 >>>> 7. Allow indication of up to two highest >>>> favoured modalities per direction, or one >>>> highest favoured and one complementing, so that >>>> good decisions can be made. >>>> That enables specifying the needs behind the >>>> use of some common types of relay services or >>>> favoured behavior of the other party. Without >>>> this, there are calls that will not be answered >>>> in the most efficient way, instead causing >>>> confusion and delay. >> I am strongly against doing this at this time. I doubt this will = ever be the right answer, but at least now, I we had consensus not to = have mechanisms like this in the document. >>=20 >>>>=20 >>>> Regards >>>>=20 >>>> Gunnar >>>>=20 >>>>=20 >>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>>> On Aug 9, 2016, at 4:49 AM, slim issue >>>>>> tracker wrote: >>>>>>=20 >>>>>> #9: Attribute specifications following the layout required by = RFC4566bis >>>>>>=20 >>>>>> The attribute specifications need to be more formal than in the = current >>>>>> draft (-04 ) >>>>>>=20 >>>>>> The following is required from attribute specifications according = to RFC >>>>>> 4566bis, section 8.2.4.1: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> "New attribute registrations are accepted according to the >>>>>> "Specification Required" policy of [RFC5226], provided that = the >>>>>> specification includes the following information: >>>>>>=20 >>>>>> o Contact Name. >>>>>>=20 >>>>>> o Contact Email Address. >>>>>>=20 >>>>>> o Attribute Name: The name of the attribute that will appear = in >>>>>> SDP). This MUST conform to the definition of . >>>>>>=20 >>>>>> o Attribute Syntax: For a value attribute (see clause 5.13), = an ABNF >>>>>> definition of the attribute value syntax (See >>>>>> Section Section 9) MUST be provided. The syntax MUST = follow the >>>>>> rule form as per Section 2.2 of [RFC5234]. This SHALL = define the >>>>>> allowable values that the attribute might take. It MAY = also >>>>>> define an extension method for the addition of future = values. For >>>>>> a property attribute, the ABNF definition is omitted as = the >>>>>> property attribute takes no values. >>>>>>=20 >>>>>> o Attribute Semantics: For a value attribute, a semantic = description >>>>>> of the values that the attribute might take MUST be = provided. The >>>>>> usage of a property attribute is described under purpose = below. >>>>>>=20 >>>>>> o Attribute Value: The name of an ABNF syntax rule defining = the >>>>>> syntax of the value. Absence of a rule name indicates = that the >>>>>> attribute takes no values. Enclosing the rule name in "[" = and "]" >>>>>> indicates that a value is optional. >>>>>>=20 >>>>>> o Usage Level: Usage level(s) of the attribute. One or more = of: >>>>>> session, media, source, dcsa, dcsa(subprotocol). For a = definition >>>>>> of source level attributes, see [RFC5576]. For a = definition of >>>>>> dcsa attributes see: = [I-D.ietf-mmusic-data-channel-sdpneg]. >>>>>>=20 >>>>>> o Charset Dependent: Whether the attribute value is subject = to the >>>>>> charset attribute or not (Yes/No). >>>>>>=20 >>>>>> o Purpose: An explanation of the purpose and usage of the = attribute. >>>>>>=20 >>>>>> o O/A Procedures: Offer/Answer procedures as explained in = [RFC3264]. >>>>>>=20 >>>>>> o Mux Category: Indication of which multiplexing "category" >>>>>> [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is = associated >>>>>> with. >>>>>>=20 >>>>>> o Reference: A reference to the specification defining the >>>>>> attribute. >>>>>> " >>>>>>=20 >>>>>>=20 >>>>>> --------------------------------------------------------------- >>>>>> Change. Add chapters on the attributes in the format described in >>>>>> RFC4566bis, section 8.2.4.1 >>>>>>=20 >>>>>> Some changes are also needed in the earlier text in the draft to = align >>>>>> with these attribute specifications. >>>>>> = -------------------------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>>> x. Specification of the "humintlang-disposition" attribute >>>>>>=20 >>>>>> o Contact Name. >>>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>>>=20 >>>>>> o Contact Email Address. >>>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>>>=20 >>>>>> o Attribute Name: >>>>>> humintlang-disposition >>>>>>=20 >>>>>> o Attribute Syntax: >>>>>> humintlang-disposition =3D "a=3Dhumintlang-disposition" = HCOLON disposition >>>>>>=20 >>>>>> o Attribute Semantics: >>>>>> If no match is possible, the value of the = "humintlang-disposition" >>>>>> session level attribute should be interrogated by the answering = party for >>>>>> the decision about how to handle the call. If the value is = "reject", then >>>>>> the call MAY be rejected. There may however be application = reasons to >>>>>> connect the call anyway. In that case the the humintlang-send = actually >>>>>> intended to be used and the humintlang-recv value of the most = likely >>>>>> combination to be initially used in the call shoud be included in = the >>>>>> answer. Emergency calls should not be rejected because of = language >>>>>> mismatch reasons. >>>>>>=20 >>>>>> If the value of the "humintlang-disposition" session = level >>>>>> attribute is "improve", then the party who inserted that value = has some >>>>>> means to improve the match e.g. by adding an interpreting agent, = e.g. a >>>>>> relay service. An answering party detecting the "improve" value = may then >>>>>> connect the call, insert all its non-matching humintlang-send and >>>>>> humintlang-recv values and look forward to receiving new sdp with = possibly >>>>>> better match. The offering party, or a service provider along the = call >>>>>> path, detecting in the answer that the = media/modality/direction/language >>>>>> indications did not match, may act to improve the match, e.g. by = adding an >>>>>> interpreting agent, e.g. a relay service, to arrange for a better = match. >>>>>> The parties involved in the call shall be informed about the = result of >>>>>> such actions by new sdp with new values in the humintlang = attributes. The >>>>>> mechanisms for such detection, decision and modifications of the = call are >>>>>> out of scope for this specification. The ability to use such = mechanisms >>>>>> shall be indicated by the value "improve" in the = "humintlang-disposition" >>>>>> session attribute. >>>>>>=20 >>>>>> When the value of the "humintlang-disposition" is = "connect" (that >>>>>> is also the default value), then the call should be connected = even without >>>>>> matching language/modality/direction indications. In that case = the the >>>>>> humintlang-send actually intended to be used and the = humintlang-recv value >>>>>> of the most likely combination to be initially used in the call = shoud be >>>>>> included in the answer. The connected parties may use in-band = actions to >>>>>> figure out if they have any human language communication means = that fulfil >>>>>> the intentions of the call. >>>>>>=20 >>>>>> o Attribute Value: >>>>>> disposition =3D = "reject"/"complete"/"improve"/disposition-extension >>>>>> disposition-extension =3D token >>>>>> The value "complete" is default. >>>>>>=20 >>>>>> o Usage Level: >>>>>> session >>>>>>=20 >>>>>> o Charset Dependent: No. >>>>>>=20 >>>>>> o Purpose: >>>>>> The attribute specifies how to handle the call when no = language or >>>>>> modality match is found. >>>>>>=20 >>>>>>=20 >>>>>> o O/A Procedures: >>>>>> If no match is possible, the value of the = "humintlang-disposition" >>>>>> session level attribute should be interrogated by the answering = party for >>>>>> the decision about how to handle the call. If the value is = "reject", then >>>>>> the call MAY be rejected. There may however be application = reasons to >>>>>> connect the call anyway. In that case the the humintlang-send = actually >>>>>> intended to be used and the humintlang-recv value of the most = likely >>>>>> combination to be initially used in the call shoud be included in = the >>>>>> answer. Emergency calls should not be rejected because of = language >>>>>> mismatch reasons. >>>>>>=20 >>>>>> An answering party detecting the "improve" value may = then connect >>>>>> the call, insert all its non-matching humintlang-send and = humintlang-recv >>>>>> values and look forward to receiving new sdp with possibly better = match. >>>>>> The offering party, or a service provider along the call path, = detecting >>>>>> in the answer that the media/modality/direction/language = indications did >>>>>> not match, may act to improve the match, e.g. by adding an = interpreting >>>>>> agent, e.g. a relay service, to arrange for a better match. The = parties >>>>>> involved in the call shall be informed about the result of such = actions by >>>>>> new sdp with new values in the humintlang attributes. >>>>>>=20 >>>>>> When the value of the "humintlang-disposition" is = "connect" (that >>>>>> is also the default value), then the call should be connected = even without >>>>>> matching language/modality/direction indications. In that case = the the >>>>>> humintlang-send actually intended to be used and the = humintlang-recv value >>>>>> of the most likely combination to be initially used in the call = shoud be >>>>>> included in the answer. >>>>>>=20 >>>>>> o Mux Category: >>>>>> NORMAL >>>>>>=20 >>>>>> o Reference: >>>>>>=20 >>>>>> draft-ietf-slim-human-language-negotiation >>>>>>=20 >>>>>> o Example: >>>>>> See the example for the humintlang-send and humintlang-recv = attributes. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Y. Specification of the humintlang-send and humintlang-recv = attributes >>>>>>=20 >>>>>> o Contact Name. >>>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>>>=20 >>>>>> o Contact Email Address. >>>>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>>>>>=20 >>>>>> o Attribute Name: >>>>>> humintlang-recv >>>>>>=20 >>>>>> humintlang-send >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> o Attribute Syntax: >>>>>> humintlang-send =3D "a=3Dhumintlang-send" HCOLON = [humintlang-value] >>>>>>=20 >>>>>> humintlang-recv =3D "a=3Dhumintlang-recv" HCOLON = [humintlang-value] >>>>>>=20 >>>>>> When used without language parameter, the = humintlang-send and >>>>>> humntlang-recv attribute indicates modality and direction for use = with the >>>>>> default language of the area and media or media/subprotocol. >>>>>>=20 >>>>>>=20 >>>>>> o Attribute Semantics: >>>>>> In order to successfully start a call, the parties need to be = aware of >>>>>> which language capabilities were negotiated, and also which = modality the >>>>>> parties prefer to use. A call can start without hesitation and be >>>>>> conducted smoothly only when answered with the modality and = language that >>>>>> best matches the most favoured combinations by the caller. There = is a >>>>>> tendency among call participants to continue using the modality = first used >>>>>> in a call, even if that is not the most favoured modality. The = call >>>>>> participants usually want to communicate about the topic of the = call, and >>>>>> not about how the call will be performed. Therefore, a mechanism = is >>>>>> provided for indication of most preferred modality/modalities of = the call >>>>>> participants together with the language attributes. >>>>>>=20 >>>>>> The humintlang-send attribute indicates modality and = language >>>>>> preferences for transmission from the indicating party. >>>>>> The humintlang-recv attribute indicates modality and = language >>>>>> preferences for reception by the indicating party. >>>>>>=20 >>>>>> The mechanism provides a "favoured" modality parameter = that MAY be >>>>>> included in the "humintlang-send" and "humintlang-recv" attribute = values >>>>>> on media level. The "favoured" modality parameter is a keyword = parameter >>>>>> with the name "favoured" and values "most" and "complement". >>>>>>=20 >>>>>> The "favoured" parameter is intended to be optionally = included >>>>>> once for each combination of media, modality and direction of = language. >>>>>> The indication is intended to carry the information that the = indicated >>>>>> combination is the highest favoured alternative if the value is = "most", >>>>>> and is a highly favoured complement to the most favoured modality = in >>>>>> another media description if the value is "complement". The value = "most" >>>>>> is allowed for more than one media/modality/direction combination = for >>>>>> cases when it is essential for the indicating party to use more = than one >>>>>> modality in the same direction. The "complement" value SHOULD not = be used >>>>>> without any "most" value in the sdp, and should only be used for = cases >>>>>> when the modality it is used with is supposed to be used for = language >>>>>> transfer simultanously with the corresponding most favoured = modality. >>>>>>=20 >>>>>> The language parameter is an optional list of languages = that the >>>>>> indicating party is prepared to use in the indicated media, = modality and >>>>>> direction. The list is a whitespace separated list of language = tags >>>>>> arranged in preference order, with highest preferred first. >>>>>>=20 >>>>>>=20 >>>>>> o Attribute Value: >>>>>>=20 >>>>>> humintlang-value =3D[*humintlang-param][*language] >>>>>> humintlang-param =3D [modality][favoured] >>>>>> modality =3D "modality=3D" = ("spoken"/"signed"/"written"/modality- >>>>>> extension) >>>>>> The value "spoken" is default for audio media. >>>>>> The value "signed" is default for video media except = when used >>>>>> with a spoken or written language. >>>>>> The value "spoken" is default for video media when used = with >>>>>> spoken language. >>>>>> The value "written" is default for text media >>>>>> favoured=3D "favoured=3D"("most"/"complement") >>>>>> modality-extension =3D token >>>>>> Modalities can be extended with further modalities and = assigned >>>>>> values indicated >>>>>> language =3D Language-Tag >>>>>> where Language-Tag is defined in RFC 5646, Section 2.1. >>>>>>=20 >>>>>>=20 >>>>>> o Usage Level: >>>>>> media, dcsa(subprotocol). >>>>>> dcsa(T140) can be indicated to carry text modality. >>>>>>=20 >>>>>> o Charset Dependent: No >>>>>>=20 >>>>>> o Purpose: >>>>>> In order to successfully start a call, the parties need to = be aware of >>>>>> which language capabilities were negotiated, and also which = modality the >>>>>> parties prefer to use. A call can start without hesitation and be >>>>>> conducted smoothly only when answered with the modality and = language that >>>>>> best matches the most favoured combinations by the caller. The = attributes >>>>>> are intended to carry the information about supported and = favoured >>>>>> languages and modalities between the communicating parties. >>>>>>=20 >>>>>> o O/A Procedures: >>>>>> Offering parties who strongly favour specific ways to = communicate >>>>>> by language are expected to indicate these ways using the = humintlang-send >>>>>> or humintlang-recv attributes with the "favoured=3Dmost" = parameter on the >>>>>> most favoured media/modality/direction combination(s). A = "favoured=3Dmost" >>>>>> indication may be included for all media/modality/direction = combinations >>>>>> that are eagerly wanted together (usually one or two per = direction). If >>>>>> one media/modality/direction is wanted together with a most = favoured >>>>>> combination but with lower urgency, then the = "favoured=3Dcomplement" should >>>>>> be indicated (usually none or one per direction). Other >>>>>> media/modality/direction combinations SHALL be left without the = "favoured" >>>>>> indication. >>>>>>=20 >>>>>> When only one language indication for a direction in the = whole sdp >>>>>> is indicated, it is regarded to be the most favoured language for = the >>>>>> indicated direction. >>>>>>=20 >>>>>> The answering party is expected to try to start the call = in the >>>>>> media/modality/direction combinations indicated with favoured = parameters >>>>>> in the languages highest preferred by the offering party. What = the >>>>>> answering party does if no match is possible for the highest = favoured >>>>>> combinations, or if no combinations are marked as highest = favoured is >>>>>> application dependent, and depending on the = "humintlang-disposition" >>>>>> session level attribute. Answering parties may select other than = the >>>>>> highest favoured combinations of the offer or add an interpreting = agent, >>>>>> e.g. a relay service to arrange for a better match in languages = and >>>>>> modalities in the call. The media/modalities/directions/languages = selected >>>>>> for language communication by the answering party shall be = indicated by >>>>>> "humintlang-send" and "humintlang-recv" attributes in the answer. = If no >>>>>> match is possible, the value of the "humintlang-disposition" = session level >>>>>> attribute should be interrogated by the answering party for the = decision >>>>>> about how to handle the call. If the value is "reject", then the = call MAY >>>>>> be rejected. There may however be application reasons to connect = the call >>>>>> anyway. In that case the the humintlang-send actually intended to = be used >>>>>> and the humintlang-recv value of the most likely combination to = be >>>>>> initially used in the call shoud be included in the answer. = Emergency >>>>>> calls should not be rejected because of language mismatch = reasons. The >>>>>> mechanism provides a "favoured" modality parameter that MAY be = included in >>>>>> the "humintlang-send" and "humintlang-recv" attribute values on = media >>>>>> level. The "favoured" modality parameter is a keyword parameter = with the >>>>>> name "favoured" and values "most" and "complement". >>>>>>=20 >>>>>> This parameter is intended to be optionally included = once for each >>>>>> combination of media, modality and direction of language. The = indication >>>>>> is intended to carry the information that the indicated = combination is >>>>>> the highest favoured alternative if the value is "most", and is a = highly >>>>>> favoured complement to the most favoured modality in another = media >>>>>> description if the value is "complement". The value "most" is = allowed for >>>>>> more than one media/modality/direction combination for cases when = it is >>>>>> essential for the indicating party to use more than one modality = in the >>>>>> same direction. The "complement" value SHOULD not be used without = any >>>>>> "most" value in the sdp, and should only be used for cases when = the >>>>>> modality it is used with is supposed to be used for language = transfer >>>>>> simultanously with the corresponding most favoured modality. >>>>>>=20 >>>>>> The offering party is expected to include all supported = languages >>>>>> in the offer. The answering party who can match sufficient >>>>>> languages/modalities and directions of the offering party, is = expected to >>>>>> include in the answer the languages selected for initial use in = the call >>>>>> and include the "favoured=3Dmost" parameter for the modalities = that the call >>>>>> is intended to start with. If no match was found, then all = supported >>>>>> languages should be included and the "favoured=3Dmost" parameter = for the >>>>>> modalities that the call is intended to start with. >>>>>>=20 >>>>>> o Mux Category: >>>>>> NORMAL >>>>>>=20 >>>>>> o Reference: >>>>>> draft-ietf-slim-human-language-negotiation >>>>>>=20 >>>>>> o Examples: (with shortened surrounding sdp) >>>>>>=20 >>>>>> Offer: >>>>>> s=3D- >>>>>> a=3Dhumintlang-disposition: connect >>>>>> m=3Daudio 34056 RTP/AVP 8 >>>>>> a=3Dhumintlang-send: modality=3Dspoken favoured=3Dmost en fr >>>>>> m=3Dvideo 36068 RTP/AVP 34 >>>>>> m=3Dtext 35072 RTP/AVP 102 >>>>>> a=3Dhumintlang-recv: modality=3Dwritten favoured=3Dmost en fr >>>>>> a=3Dhumintlang-send: modality=3Dwritten en fr >>>>>>=20 >>>>>> Answer >>>>>> s=3D- >>>>>> a=3Dhumintlang-disposition: connect >>>>>> m=3Daudio 34066 RTP/AVP 8 >>>>>> a=3Dhumintlang-recv: modality=3Dspoken favoured=3Dmost en >>>>>> m=3Dvideo 0 RTP/AVP 34 >>>>>> m=3Dtext 35092 RTP/AVP 102 >>>>>> a=3Dhumintlang-send: modality=3Dwritten favoured=3Dmost en >>>>>>=20 >>>>>>=20 >>>>>> This sdp exchange indicates that the offering party wants the = call to be >>>>>> connected regardless of the outcome of the negotiation, and that = the most >>>>>> favoured modality and language is to speak English, but speaking = French is >>>>>> also possible. >>>>>> The offering party also offers video, but with no intention to = use it for >>>>>> language. >>>>>> The incoming language is preferred in written real-time text = form. >>>>>> The offering party can accept to send English or French text if = the other >>>>>> party is not capable of receiving spoken English. >>>>>>=20 >>>>>> The answering party accepts to connect the call, and use the = favoured >>>>>> modalities in English. No video capability is available, so the = video >>>>>> offer is rejected, but the call connected, and the answering = party can >>>>>> start with a written text greeting and expect to get spoken = response. >>>>>>=20 >>>>>> Note: Both the humintlang-disposition value "connect" and the = modalities >>>>>> indicated are the default values, so they could in this case have = been >>>>>> left out with the same result. >>>>>>=20 >>>>>> -- >>>>>> = -------------------------------------+------------------------------------= - >>>>>> Reporter: | Owner: = draft-ietf-slim- >>>>>> gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org >>>>>> Type: defect | Status: new >>>>>> Priority: major | Milestone: >>>>>> Component: negotiating-human- | Version: >>>>>> language | Keywords: Attribute >>>>>> Severity: - | >>>>>> = -------------------------------------+------------------------------------= - >>>>>>=20 >>>>>> Ticket URL: >>>>>> slim >>>>>>=20 >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/slim >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=C3=B6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> It has been observed that one's nose is never so happy as when >>> it is thrust into the affairs of another, from which some >>> physiologists have drawn the inference that the nose is devoid >>> of the sense of smell. >>> --Ambrose Bierce, "The Devil's Dictionary" >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim = >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim = --Apple-Mail=_CFB4A8FC-1F89-4D2A-89A9-26E06E6F03DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am not worried about applying a language to m=3Dapplication. =  I don=E2=80=99t think anyone will be confused.

Brian

On Aug 12, 2016, at 5:24 PM, Gunnar = Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-08-12 kl. 22:58, skrev Brian = Rosen:
I agree. =  Some detail below
Thanks Brian for being explicit.
I hope we can get = good opportunities to discuss the points one by one.
One point that = amazed me was that you did not want the modality parameter. How do you = then propose to know where to find e.g. the written modality in an = WebRTC sdp?

Thanks,
Gunnar
On Aug 12, 2016, at 4:14 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

Hi Gunnar,

These create a = complex mechanism that goes beyond
what we agreed to do = for the initial version.
I'm happy to work with you on = these mechanisms or
something else for a revision or = extension.

--Randy

At 9:33 PM +0200 8/12/16, Gunnar Hellstr=C3=B6m wrote:

Den = 2016-08-09 kl. 15:06, skrev Brian Rosen:
I agree that we need to conform to the 4566 = template.

I don't agree with changing the = definition of the attribute.
I find it hard = to see that you do not agree in
any of the proposed = changes in the definitions.
Here they are in a numbered = list.

1. Move the session level parameter = about
rejecting or connecting the call in case of no
language match to session level. There is no
logically correct place for this parameter in
the= media level attributes.
I=E2=80=99= m not worried about having this be at a media level.  The recipient = can always reject the call for whatever reason it wants. The sender can = always drop the call if it doesn=E2=80=99t like the result of = negotiations.  t could easily construct use cases where what you = want is media decisions, not session decisions (so, if you can=E2=80=99t = give me English text, I don=E2=80=99t care if you can give me Spanish = video, I want to fail the call).  It=E2=80=99s all advisory, and = I=E2=80=99d prefer to keep it where it is.

2. Revert the default value of the rejecting or
connecting the call at no match to be
connecting.= That matches the scope of the
parameter better, and is in = line with the
discussion in the mail list.
I don=E2=80=99t really care about = this.  Again, this is at best advisory, and either end can reject = any time.  If you rely on defaults to get what you want, you = deserve what you get.

3. Add a = value "improve" to the session level
attribute, with the = meaning "I can improve
language matches by introduction of = means not
initially indicated. ( such as a caller not
invoking a relay service initially, but after
the= answer when it shows that a relay service
is needed. )
I am strongly against doing this = ever.  If you need to renegotiate, drop the call and try again, = probably with some different path (i.e. with relay).

4. Introduce a modality parameter in the
humintlang-send and humintlang-recv attribute
values. Default values handle most cases, but
there are cases when an explicit value is
needed,= because it is not evident from the
m-line and the = language tag what modality
indicated. This is especially = true for
m=3Dapplication cases.
(A complex = alternative would be to specify all
cases we know now = explicitly of language use
where it is not explicit by the = mime type and
the language tag what modality is intended, = but
I think that is too inflexible. )
I am strongly against doing this = ever.  I think it=E2=80=99s a bad idea.

5. Combine all languages for one media,
modality = and direction in a space separated
list as value to one = humintlang-send or
humintlang-recv attribute. That matches = the
format of the SIP Accept-Language field value.
It also matches the logic of only indicating one highest = favoured language.
It would be possible to have only one = language
per humintlang-send or humintlang-recv
attribute and include multiple attributes per
media and direction. But then the syntax of the
most favoured parameter gets less logical.
Therefore I propose the changed attribute
syntax.
I am strongly = against doing this at this time.  I=E2=80=99m not sure if makes any = sense, and I=E2=80=99d like to get some experience before we make = decisions in this area.

6. = Introduce a mark for most favoured media,
meaning that the = first language in the value
list of the corresponding = attribute is the most
favoured for that direction. This = can enable
the negotiation to result in good decisions = so
that language exchange gets efficient. Without
it, the start of the call will be in randomly
selected modality and language among a set with
undefined relative favour, causing problems to
correct the modality and language when it gets
initially wrong.
I = really don=E2=80=99t think this is the best way to handle interactions = between media, but regardless, at this time, I don=E2=80=99t think we = should have mechanisms like this.

7. Allow = indication of up to two highest
favoured modalities per = direction, or one
highest favoured and one complementing, = so that
good decisions can be made.
That = enables specifying the needs behind the
use of some common = types of relay services or
favoured behavior of the other = party. Without
this, there are calls that will not be = answered
in the most efficient way, instead causing
confusion and delay.
I = am strongly against doing this at this time.  I doubt this will = ever be the right answer, but at least now, I we had consensus not to = have mechanisms like this in the document.


Regards

Gunnar



Brian


On Aug 9, 2016, at 4:49 = AM, slim issue
tracker <trac+slim@tools.ietf.org> wrote:

#9: Attribute specifications following the layout required by = RFC4566bis

The attribute specifications = need to be more formal than in the current
draft (-04 )

The following is required from attribute = specifications according to RFC
4566bis, section = 8.2.4.1:



"New = attribute registrations are accepted according to the
    "Specification Required" policy of = [RFC5226], provided that the
    specification includes the following = information:

    o =  Contact Name.

    o=  Contact Email Address.

    o  Attribute Name: The name of = the attribute that will appear in
       SDP).  This = MUST conform to the definition of <att-field>.

    o  Attribute Syntax: For a value = attribute (see clause 5.13), an ABNF
       definition of the = attribute value <att-value> syntax (See
       Section Section 9) = MUST be provided.  The syntax MUST follow the
       rule form as per = Section 2.2 of [RFC5234].  This SHALL define the
       allowable values = that the attribute might take.  It MAY also
       define an extension = method for the addition of future values.  For
       a property = attribute, the ABNF definition is omitted as the
       property attribute = takes no values.

    o =  Attribute Semantics: For a value attribute, a semantic = description
       of = the values that the attribute might take MUST be provided.  The
       usage of a property = attribute is described under purpose below.

    o  Attribute Value: The name of = an ABNF syntax rule defining the
       syntax of the = value.  Absence of a rule name indicates that the
       attribute takes no = values.  Enclosing the rule name in "[" and "]"
       indicates that a = value is optional.

    o =  Usage Level: Usage level(s) of the attribute.  One or more = of:
       session, = media, source, dcsa, dcsa(subprotocol).  For a definition
       of source level = attributes, see [RFC5576].  For a definition of
       dcsa attributes = see: [I-D.ietf-mmusic-data-channel-sdpneg].

    o  Charset Dependent: Whether = the attribute value is subject to the
       charset attribute = or not (Yes/No).

    o =  Purpose: An explanation of the purpose and usage of the = attribute.

    o =  O/A Procedures: Offer/Answer procedures as explained in = [RFC3264].

    o =  Mux Category: Indication of which multiplexing "category"
       [I-D.ietf-mmusic-sdp-= mux-attributes] an attribute is associated
       with.

    o  Reference: A = reference to the specification defining the
       attribute.
"


---------------------------------------------------------------=
Change. Add chapters on the attributes in the format = described in
RFC4566bis, section 8.2.4.1

Some changes are also needed in the earlier text in the draft = to align
with these attribute specifications.
---------------------------------------------------------------= -----


x. Specification of = the "humintlang-disposition" attribute

    o  Contact Name.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXX

    o  Contact Email = Address.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    o  Attribute = Name:
    humintlang-disposition

    o  Attribute = Syntax:
    humintlang-disposition =3D = "a=3Dhumintlang-disposition" HCOLON disposition

    o  Attribute Semantics:
    If no match is possible, the value of = the "humintlang-disposition"
session level attribute = should be interrogated by the answering party for
the = decision about how to handle the call. If the value is "reject", then
the call MAY be rejected. There may however be application = reasons to
connect the call anyway. In that case the the = humintlang-send actually
intended to be used and the = humintlang-recv value of the most likely
combination to be = initially used in the call shoud be included in the
answer. = Emergency calls should not be rejected because of language
mismatch reasons.

         If the = value of the "humintlang-disposition" session level
attribute is "improve", then the party who inserted that = value has some
means to improve the match e.g. by adding = an interpreting agent, e.g. a
relay service. An answering = party detecting the "improve" value may then
connect the = call, insert all its non-matching humintlang-send and
humintlang-recv values and look forward to receiving new sdp = with possibly
better match. The offering party, or a = service provider along the call
path, detecting in the = answer that the media/modality/direction/language
indications did not match, may act to improve the match, e.g. = by adding an
interpreting agent, e.g. a relay service, to = arrange for a better match.
The parties involved in the = call shall be informed about the result of
such actions by = new sdp with new values in the humintlang attributes. The
mechanisms for such detection, decision and modifications of = the call are
out of scope for this specification. The = ability to use such mechanisms
shall be indicated by the = value "improve" in the "humintlang-disposition"
session = attribute.

         When = the value of the "humintlang-disposition" is "connect" (that
is also the default value), then the call should be connected = even without
matching language/modality/direction = indications. In that case the the
humintlang-send actually = intended to be used and the humintlang-recv value
of the = most likely combination to be initially used in the call shoud be
included in the answer. The connected parties may use in-band = actions to
figure out if they have any human language = communication means that fulfil
the intentions of the = call.

    o =  Attribute Value:
    disposition = =3D "reject"/"complete"/"improve"/disposition-extension
    disposition-extension =3D token
    The value "complete" is default.

    o  Usage = Level:
    session

    o  Charset Dependent: No.

    o  Purpose:
    The attribute specifies how to handle = the call when no language or
modality match is found.


    o =  O/A Procedures:
         If no = match is possible, the value of the "humintlang-disposition"
session level attribute should be interrogated by the = answering party for
the decision about how to handle the = call. If the value is "reject", then
the call MAY be = rejected. There may however be application reasons to
connect the call anyway. In that case the the humintlang-send = actually
intended to be used and the humintlang-recv value = of the most likely
combination to be initially used in the = call shoud be included in the
answer. Emergency calls = should not be rejected because of language
mismatch = reasons.

         An = answering party detecting the "improve" value may then connect
the call, insert all its non-matching humintlang-send and = humintlang-recv
values and look forward to receiving new = sdp with possibly better match.
The offering party, or a = service provider along the call path, detecting
in the = answer that the media/modality/direction/language indications did
not match, may act to improve the match, e.g. by adding an = interpreting
agent, e.g. a relay service, to arrange for a = better match. The parties
involved in the call shall be = informed about the result of such actions by
new sdp with = new values in the humintlang attributes.

         When = the value of the "humintlang-disposition" is "connect" (that
is also the default value), then the call should be connected = even without
matching language/modality/direction = indications. In that case the the
humintlang-send actually = intended to be used and the humintlang-recv value
of the = most likely combination to be initially used in the call shoud be
included in the answer.

    o  Mux Category:
    NORMAL

    o  Reference:

          &nb= sp;draft-ietf-slim-human-language-negotiation

    o  Example:
    See the example for the = humintlang-send and humintlang-recv attributes.



Y. Specification of the = humintlang-send and humintlang-recv attributes

    o  Contact Name.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    o  Contact Email = Address.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    o  Attribute = Name:
    humintlang-recv

    humintlang-send



    o  Attribute Syntax:
         humintlan= g-send  =3D  "a=3Dhumintlang-send" HCOLON = [humintlang-value]

         humintlan= g-recv  =3D  "a=3Dhumintlang-recv" HCOLON = [humintlang-value]

         When = used without language parameter, the humintlang-send and
humntlang-recv attribute indicates modality and direction for = use with the
default language of the area and media or = media/subprotocol.


    o  Attribute Semantics:
    In order to successfully start a = call, the parties need to be aware of
which language = capabilities were negotiated, and also which modality the
parties prefer to use. A call can start without hesitation = and be
conducted smoothly only when answered with the = modality and language that
best matches the most favoured = combinations by the caller. There is a
tendency among call = participants to continue using the modality first used
in = a call, even if that is not the most favoured modality. The call
participants usually want to communicate about the topic of = the call, and
not about how the call will be performed. = Therefore, a mechanism is
provided for indication of most = preferred modality/modalities of the call
participants = together with the language attributes.

         The = humintlang-send attribute indicates modality and language
preferences for transmission from the indicating party.
         The = humintlang-recv attribute indicates modality and language
preferences for reception by the indicating party.

         The = mechanism provides a "favoured" modality parameter that MAY be
included in the "humintlang-send" and "humintlang-recv" = attribute values
on media level. The "favoured" modality = parameter is a keyword parameter
with the name "favoured" = and values "most" and "complement".

         The = "favoured" parameter is intended to be optionally included
once for each combination of media, modality and direction of = language.
The indication is intended to carry the = information that the indicated
combination is the highest = favoured alternative if the value is "most",
and is a = highly favoured complement to the most favoured modality in
another media description if the value is "complement". The = value "most"
is allowed for more than one = media/modality/direction combination for
cases when it is = essential for the indicating party to use more than one
modality in the same direction. The "complement" value SHOULD = not be used
without any "most" value in the sdp, and = should only be used for cases
when the modality it is used = with is supposed to be used for language
transfer = simultanously with the corresponding most favoured modality.

         The = language parameter is an optional list of languages that the
indicating party is prepared to use in the indicated media, = modality and
direction. The list is a whitespace separated = list of language tags
arranged in preference order, with = highest preferred first.


    o  Attribute Value:

     humintlang-value = =3D[*humintlang-param][*language]
         humintlan= g-param =3D  [modality][favoured]
         modality = =3D "modality=3D" ("spoken"/"signed"/"written"/modality-
extension)
         The = value "spoken" is default for audio media.
         The = value "signed" is default for video media except when used
with a spoken or written language.
         The = value "spoken" is default for video media when used with
spoken language.
         The = value "written" is default for text media
         favoured=3D= "favoured=3D"("most"/"complement")
         modality-= extension =3D token
         Modalitie= s can be extended with further modalities and assigned
values indicated
         language =         =3D =  Language-Tag
         where = Language-Tag is defined in RFC 5646, Section 2.1.


    o  Usage = Level:
     media, = dcsa(subprotocol).
         dcsa(T140= ) can be indicated to carry text modality.

    o  Charset Dependent: No

    o  Purpose:
     In order to successfully start = a call, the parties need to be aware of
which language = capabilities were negotiated, and also which modality the
parties prefer to use. A call can start without hesitation = and be
conducted smoothly only when answered with the = modality and language that
best matches the most favoured = combinations by the caller. The attributes
are intended to = carry the information about supported and favoured
languages= and modalities between the communicating parties.

    o  O/A Procedures:
         Offering = parties who strongly favour specific ways to communicate
by = language are expected to indicate these ways using the = humintlang-send
or humintlang-recv attributes with the = "favoured=3Dmost" parameter on the
most favoured = media/modality/direction combination(s). A "favoured=3Dmost"
indication may be included for all media/modality/direction = combinations
that are eagerly wanted together (usually one = or two per direction). If
one media/modality/direction is = wanted together with a most favoured
combination but with = lower urgency, then the "favoured=3Dcomplement" should
be = indicated (usually none or one per direction). Other
media/modality/direction combinations SHALL be left without = the "favoured"
indication.

         When = only one language indication for a direction in the whole sdp
is indicated, it is regarded to be the most favoured language = for the
indicated direction.

         The = answering party is expected to try to start the call in the
media/modality/direction combinations indicated with favoured = parameters
in the languages highest preferred by the = offering party. What the
answering party does if no match = is possible for the highest favoured
combinations, or if = no combinations are marked as highest favoured is
application dependent, and depending on the = "humintlang-disposition"
session level attribute. = Answering parties may select other than the
highest = favoured combinations of the offer or add an interpreting agent,
e.g. a relay service to arrange for a better match in = languages and
modalities in the call. The = media/modalities/directions/languages selected
for = language communication by the answering party shall be indicated by
"humintlang-send" and "humintlang-recv" attributes in the = answer. If no
match is possible, the value of the = "humintlang-disposition" session level
attribute should be = interrogated by the answering party for the decision
about = how to handle the call. If the value is "reject", then the call MAY
be rejected. There may however be application reasons to = connect the call
anyway. In that case the the = humintlang-send actually intended to be used
and the = humintlang-recv value of the most likely combination to be
initially used in the call shoud be included in the answer. = Emergency
calls should not be rejected because of language = mismatch reasons.    The
mechanism provides = a "favoured" modality parameter that MAY be included in
the = "humintlang-send" and "humintlang-recv" attribute values on media
level. The "favoured" modality parameter is a keyword = parameter with the
name "favoured" and values "most" and = "complement".

         This = parameter is intended to be optionally included once for each
combination of media, modality and direction of language. The = indication
is intended to carry the information that the = indicated     combination is
the = highest favoured alternative if the value is "most", and is a highly
favoured complement to the most favoured modality in another = media
description if the value is "complement". The value = "most" is allowed for
more than one = media/modality/direction combination for cases when it is
essential for the indicating party to use more than one = modality in the
same direction. The "complement" value = SHOULD not be used without any
"most" value in the sdp, = and should only be used for cases when the
modality it is = used with is supposed to be used for language transfer
simultanously with the corresponding most favoured = modality.

         The = offering party is expected to include all supported languages
in the offer. The answering party who can match sufficient
languages/modalities and directions of the offering party, is = expected to
include in the answer the languages selected = for initial use in the call
and include the = "favoured=3Dmost" parameter for the modalities that the call
is intended to start with. If no match was found, then all = supported
languages should be included and the = "favoured=3Dmost" parameter for the
modalities that the = call is intended to start with.

    o  Mux Category:
    NORMAL

    o  Reference:
         draft-iet= f-slim-human-language-negotiation

    o  Examples: (with shortened = surrounding sdp)

    Offer:
    s=3D-
    a=3Dhumintlang-disposition: = connect
    m=3Daudio 34056 RTP/AVP = 8
    a=3Dhumintlang-send: = modality=3Dspoken favoured=3Dmost en fr
    m=3Dvideo 36068 RTP/AVP 34
    m=3Dtext 35072 RTP/AVP 102
    a=3Dhumintlang-recv: modality=3Dwritten= favoured=3Dmost en fr
    a=3Dhumintlang-send: modality=3Dwritten= en fr

    Answer
    s=3D-
    a=3Dhumintlang-disposition: = connect
    m=3Daudio 34066 RTP/AVP = 8
    a=3Dhumintlang-recv: = modality=3Dspoken favoured=3Dmost en
    m=3Dvideo 0 RTP/AVP 34
    m=3Dtext 35092 RTP/AVP 102
    a=3Dhumintlang-send: modality=3Dwritten= favoured=3Dmost en


This sdp = exchange indicates that the offering party wants the call to be
connected regardless of the outcome of the negotiation, and = that the most
favoured modality and language is to speak = English, but speaking French is
also possible.
The offering party also offers video, but with no intention = to use it for
language.
The incoming = language is preferred in written real-time text form.
The = offering party can accept to send English or French text if the other
party is not capable of receiving spoken English.

The answering party accepts to connect the = call, and use the favoured
modalities in English. No video = capability is available, so the video
offer is rejected, = but the call connected, and the answering party can
start = with a written text greeting and expect to get spoken response.

Note: Both the humintlang-disposition value = "connect" and the modalities
indicated are the default = values, so they could in this case have been
left out with = the same result.

--
-------------------------------------+-------------------------= ------------
Reporter: =             &n= bsp;           &nbs= p; |      Owner:  draft-ietf-slim-
  gunnar.hellstrom@omnitor.se =        |  negotiating-human-language@ietf.org
     Type:  defect =             &n= bsp;     |     Status: =  new
Priority:  major =             &n= bsp;      |  Milestone:
Component:  negotiating-human- =       |    Version:
  language =             &n= bsp;           &nbs= p; |   Keywords:  Attribute
Severity: =  - =             &n= bsp;          |
-------------------------------------+-------------------------= ------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/9>
slim <https://tools.ietf.org/slim/>

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim
--
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 = 288

--
Randall = Gellens
Opinions are personal;    facts are = suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It has been observed that one's nose is never so happy as = when
it is thrust into the affairs of another, from which = some
physiologists have drawn the inference that the nose = is devoid
of the sense of smell.
       --Ambrose Bierce, = "The Devil's Dictionary"
_______________________________________________SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

_______________________________________________
SLIM mailing = list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

= --Apple-Mail=_CFB4A8FC-1F89-4D2A-89A9-26E06E6F03DD-- From nobody Mon Aug 15 09:35:42 2016 Return-Path: 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 D77CF12D1D5; Mon, 15 Aug 2016 09:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 iWDtumccR6fP; Mon, 15 Aug 2016 09:35:39 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87ABA12B01B; Mon, 15 Aug 2016 09:35:39 -0700 (PDT) Received: from localhost ([::1]:38555 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZKrS-0005sC-Qn; Mon, 15 Aug 2016 09:35:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:35:38 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/2#comment:1 Message-ID: <082.d873876a6dd8e2cc992dda014302619e@tools.ietf.org> References: <067.11923dfa77eca4495f14a45e29a1e674@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <067.11923dfa77eca4495f14a45e29a1e674@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815163539.87ABA12B01B@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:35:39 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #2 (negotiating-human-language): In real-time document, modalities in introduction should be spoken, signed or written X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:35:41 -0000 #2: In real-time document, modalities in introduction should be spoken, signed or written Comment (by nrooney@gsma.com): Chairs: this is fine. Randall please make the change. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: trivial | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 09:37:00 2016 Return-Path: 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 86B2312D685; Mon, 15 Aug 2016 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 vtxtYsZQxhuD; Mon, 15 Aug 2016 09:36:57 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9C912B01B; Mon, 15 Aug 2016 09:36:57 -0700 (PDT) Received: from localhost ([::1]:38584 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZKsi-0001nU-QY; Mon, 15 Aug 2016 09:36:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:36:56 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/3#comment:1 Message-ID: <082.45c7f068acd7eda24d66d71f41c2000d@tools.ietf.org> References: <067.24db4f15e031c570feed49180f09a8fd@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <067.24db4f15e031c570feed49180f09a8fd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815163657.4D9C912B01B@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:36:57 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #3 (negotiating-human-language): Delete (known as voice carry over) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:36:58 -0000 #3: Delete (known as voice carry over) Comment (by nrooney@gsma.com): Chairs: this is fine, Randall please remove brackets. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: simultaneous | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 09:39:51 2016 Return-Path: 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 0C1A912D0A8; Mon, 15 Aug 2016 09:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 T9Q8osJMr3s4; Mon, 15 Aug 2016 09:39:43 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A8912B01B; Mon, 15 Aug 2016 09:39:43 -0700 (PDT) Received: from localhost ([::1]:38607 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZKvL-0008Ls-BF; Mon, 15 Aug 2016 09:39:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:39:39 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/4#comment:2 Message-ID: <082.9f834d98240ba9e456e4d0abd77d73da@tools.ietf.org> References: <067.2e58384b177c3fa6dc148d6953ae10e3@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <067.2e58384b177c3fa6dc148d6953ae10e3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815163943.82A8912B01B@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:39:43 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #4 (negotiating-human-language): Section 3 has many informal references. Reword the section. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:39:45 -0000 #4: Section 3 has many informal references. Reword the section. Comment (by nrooney@gsma.com): Chairs: this is fine. Randall - suggestion here is to remove this or to put in direct document references. Gunnar: if you know about specific references please share them! -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 09:44:07 2016 Return-Path: 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 B3F3012D592; Mon, 15 Aug 2016 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 UAh8gShKWjlP; Mon, 15 Aug 2016 09:44:04 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E39B12D0A8; Mon, 15 Aug 2016 09:44:04 -0700 (PDT) Received: from localhost ([::1]:38649 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZKzc-00038M-FF; Mon, 15 Aug 2016 09:44:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:44:04 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/5#comment:1 Message-ID: <082.1ebcfb1317ea2525186b7cb55edf8296@tools.ietf.org> References: <067.dddc6438e41ce7624872be9398d943d7@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <067.dddc6438e41ce7624872be9398d943d7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815164404.9E39B12D0A8@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:44:04 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #5 (negotiating-human-language): Improve paragraph on relay services in section 1. Introduction. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:44:05 -0000 #5: Improve paragraph on relay services in section 1. Introduction. Comment (by nrooney@gsma.com): Chairs: Randall please decide on this one. We're unsure whether a distinction between [2] and [3] are worth making. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: relay services | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 09:52:10 2016 Return-Path: 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 2E82412D903; Mon, 15 Aug 2016 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 Tmvk1fwZZz6Z; Mon, 15 Aug 2016 09:52:06 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850F312D80B; Mon, 15 Aug 2016 09:50:34 -0700 (PDT) Received: from localhost ([::1]:38787 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZL5t-0004nd-II; Mon, 15 Aug 2016 09:50:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:50:33 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:4 Message-ID: <082.b0f475e92bf8ec7091bbbead2cf1f80e@tools.ietf.org> References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815165034.850F312D80B@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:50:34 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:52:08 -0000 #6: Collect information on modality in separate section for clarity Comment (by bernard_aboba@hotmail.com): I'm a bit confused by the meaning of "modality parameter". Are you proposing that an assumption be made about language if signing is not explicitly indicated? For example, if there is no language indicated for a video m-line, or just "English" (but not ASL), what should we assume "by default"? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 09:57:45 2016 Return-Path: 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 46A1412D1D5; Mon, 15 Aug 2016 09:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 oCDSFzRxXSsE; Mon, 15 Aug 2016 09:57:42 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAD412D508; Mon, 15 Aug 2016 09:54:29 -0700 (PDT) Received: from localhost ([::1]:38876 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZL9e-00051X-PF; Mon, 15 Aug 2016 09:54:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:54:26 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:2 Message-ID: <082.6d57eb8e8eac2bdfb6e935743d5efdd8@tools.ietf.org> References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815165429.2BAD412D508@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:54:29 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:57:44 -0000 #7: The notation for Advisory vs Required is not logical and needs revision Comment (by nrooney@gsma.com): Chairs: Randall - can you respond to this when you have a chance? It seems like there are some interesting points here which should be discussed on- list (e.g. the default value perhaps should change). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: reject | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 10:00:19 2016 Return-Path: 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 14DD812D619; Mon, 15 Aug 2016 10:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 NEpyy0aXmw9Y; Mon, 15 Aug 2016 10:00:17 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E5312D89A; Mon, 15 Aug 2016 09:56:58 -0700 (PDT) Received: from localhost ([::1]:39023 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZLC6-0005bj-4H; Mon, 15 Aug 2016 09:56:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:56:58 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:1 Message-ID: <082.a0cc7c929af8b009795abffbf85f572d@tools.ietf.org> References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815165658.44E5312D89A@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:56:58 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:00:19 -0000 #8: Introduce a section on most favoured modality Comment (by nrooney@gsma.com): Chairs: This topic has been discussed at length in WG meetings and on- list. The decision was not to include this within this document, but it could be in scope for another piece of work. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 10:00:32 2016 Return-Path: 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 30AAF12D0B1; Mon, 15 Aug 2016 10:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 TL2tPYYC02oF; Mon, 15 Aug 2016 10:00:29 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1910D12D678; Mon, 15 Aug 2016 09:57:26 -0700 (PDT) Received: from localhost ([::1]:39048 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZLCX-0006HO-Vd; Mon, 15 Aug 2016 09:57:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:57:25 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:2 Message-ID: <082.75b128b3693a5ac691ac419bf0088816@tools.ietf.org> References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815165726.1910D12D678@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:57:26 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:00:31 -0000 #8: Introduce a section on most favoured modality Changes (by nrooney@gsma.com): * status: new => closed * resolution: => wontfix -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: wontfix Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 10:00:53 2016 Return-Path: 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 D29E212D0B6; Mon, 15 Aug 2016 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 tRDqHeBI3bur; Mon, 15 Aug 2016 10:00:50 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2264E12D5D1; Mon, 15 Aug 2016 09:59:48 -0700 (PDT) Received: from localhost ([::1]:39107 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZLEp-0006Vh-Vl; Mon, 15 Aug 2016 09:59:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 16:59:47 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/9#comment:1 Message-ID: <082.d787d561331788eed1749ed6329894dc@tools.ietf.org> References: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <067.235e59bc8c6df57527c2e83d555c8269@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815165948.2264E12D5D1@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 09:59:48 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:00:52 -0000 #9: Attribute specifications following the layout required by RFC4566bis Comment (by nrooney@gsma.com): Chairs: we should aim to conform to RFC4566bis. Randall: please take a look at RFC4566bis and make changes as you see fit. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: - | Keywords: Attribute | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 10:01:10 2016 Return-Path: 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 97BD7127058; Mon, 15 Aug 2016 10:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 Ucaayb9whMFF; Mon, 15 Aug 2016 10:01:08 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B269012D619; Mon, 15 Aug 2016 10:00:45 -0700 (PDT) Received: from localhost ([::1]:39140 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZLFh-0006cY-Dp; Mon, 15 Aug 2016 10:00:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 17:00:41 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:5 Message-ID: <082.d444aff688032de364a2e65fc586c0ba@tools.ietf.org> References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815170045.B269012D619@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 10:00:45 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:01:09 -0000 #6: Collect information on modality in separate section for clarity Comment (by nrooney@gsma.com): Chairs: this is a summary of the other issues, so is invalid, will close. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 10:01:18 2016 Return-Path: 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 953ED12D614; Mon, 15 Aug 2016 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 utfaqVMnp7Nb; Mon, 15 Aug 2016 10:01:12 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7554312D0DC; Mon, 15 Aug 2016 10:00:56 -0700 (PDT) Received: from localhost ([::1]:39147 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZLFt-0006d4-IR; Mon, 15 Aug 2016 10:00:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 17:00:53 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:6 Message-ID: <082.520d809e30eb25bc269a57493a32061e@tools.ietf.org> References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815170056.7554312D0DC@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 10:00:56 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:01:13 -0000 #6: Collect information on modality in separate section for clarity Changes (by nrooney@gsma.com): * status: new => closed * resolution: => invalid -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: invalid Severity: In WG Last Call | Keywords: modality | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 10:12:23 2016 Return-Path: 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 E1DDF127058 for ; Mon, 15 Aug 2016 10:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com 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 3R50udzYwz9F for ; Mon, 15 Aug 2016 10:12:19 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0076.outbound.protection.outlook.com [104.47.0.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197F5127071 for ; Mon, 15 Aug 2016 10:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0vuPXJLcz6/0l/ITdO4ssK3Q1f5sY5/pXNFrZXhrQ6E=; b=Kkc86/V97eHQWiWfUie7/EP5cfKduEGyz3pHK9GZ+/zjr4DgC5+5zVg1sZZZHyyRXcYI1WUePEPgYpTMB66O4ZUhm95XjovX6xWN+I9MrdBpN9ylxfLJ95rujnNsLRYzqoAXky/LBoEbfeQVAXHjIEI56apo+U0H/O2BV1qUeo8= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2062.eurprd04.prod.outlook.com (10.166.141.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Mon, 15 Aug 2016 17:12:14 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0587.005; Mon, 15 Aug 2016 17:12:14 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: [Slim] Documents in WGLC Thread-Index: AQHR5AVLt4Myud10Q0SJmSujOFJoj6BKaEyA Date: Mon, 15 Aug 2016 17:12:14 +0000 Message-ID: <50CFEBF2-EF1A-4720-9781-BE4FC34BAD7F@gsma.com> References: <56128392-5138-487C-9D99-151BC4C13D34@gsma.com> In-Reply-To: <56128392-5138-487C-9D99-151BC4C13D34@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [62.189.0.100] x-ms-office365-filtering-correlation-id: 2de78248-c42e-4bc8-702c-08d3c52f4dd6 x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2062; 6:dmSsUiKl7/w3OSYl1Iy5TyZP29LK/P2p2418BFdRTvt77svOcNRoxynTGsE4TUDk/Kqx93vCQyX2XmbhQGzaqwNlbWkTOn8g/2+nP4hcLHgJMjHkcqunhJv1G7QraHr0n3tEwWhgWgkdP82flJhZjZYYb4voJqgH38VN10Cr3NrWAwyhx/hTVzwzbdOSXnTMcf24wpD5+mMkW7SuZV6Tg8Fejootb88VFMEOa/gLJBcX/5x1u6DEf0q1nTkbqJKDrZoFnN9bDdVN0QA8bkCCShf+aU3kxNys3MUCXD9xaJc=; 5:3hhacol92RYeUt1ir8o6nbLpBWee7vytlMPOUa3s5rQdBUtX9ORb1YOuM+zvfU2NoFBXh74j645Af5NoRnAKAmEBsfLqx+RVegakteiZItMktjoD3G5GyBGQP6wu/QtvOpBouv8CXQrltGMilrpqYQ==; 24:U45OaUzLcOmoeVs9GJlqhuIO+yAynk6Ruiu9QeMg9dacF70W1snMUUbjxcS2xh+U7hQpPjRode95cbGMuMFCM0NpQG6yNdrH2duXnHcSHws=; 7:xwQT43Hh9P+nwIwWWXk+OG0uuER/dr1aASbggJTDwCWSGkrC+vei3vfutZu5M7XOqxuD/p0Y7GuLj6Mw6hN5Ie5lkVh2gYhkHQpCHv36rzbsbBOT+39UozXMsfct0eqOZmjSV5OZAcouMg0NN5GfKdsnVRJPha0JTmo/xDNLaATMwrIaqRa6zrQCqxMNtlBebffq2MHaeBe96RcdbLZAmBY90jiBKkcVQRN0LiicGasOauUnqar9a4OsIaIDCF8T x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2062; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR0401MB2062; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2062; x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(66654002)(52044002)(189002)(24454002)(51914003)(53754006)(199003)(189998001)(3660700001)(107886002)(10400500002)(11100500001)(68736007)(76176999)(8676002)(82746002)(83716003)(122556002)(36756003)(50226002)(3846002)(586003)(6116002)(110136002)(102836003)(97736004)(87936001)(450100001)(86362001)(2351001)(19580405001)(57306001)(92566002)(2501003)(15975445007)(19617315012)(106356001)(66066001)(77096005)(19580395003)(2900100001)(2950100001)(50986999)(5890100001)(16236675004)(5640700001)(101416001)(1730700003)(81166006)(81156014)(33656002)(3280700002)(105586002)(106116001)(7846002)(7736002)(7906003)(5002640100001)(2906002)(8936002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2062; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_50CFEBF2EF1A47209781BE4FC34BAD7Fgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2016 17:12:14.8795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2062 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR0401MB2062.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] Documents in WGLC X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:12:22 -0000 --_000_50CFEBF2EF1A47209781BE4FC34BAD7Fgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The chairs have reviewed the tickets we currently have and have asked the a= uthor to make edits where necessary. All the tickets we had were for the dr= aft-ietf-slim-negotiating-human-language-04 draft. This means we likely hav= e not had the required number of reviewers for the draft-ietf-slim-multilan= gcontent-04[2] draft. Therefore, here are the actions and next steps. * ACTION: Randall, please take a look at the comments on the tickets an= d make changes where necessary. * ACTION: All, please review the draft-ietf-slim-multilangcontent-04[2]= draft, and send tickets if changes are needed * Please also let us know you have read it, as then we know how many= reviewers there have been. * NEXT STEP: After changes have been made, Bernard will start pushing t= he document through the RFC process (requesting AD reviews etc.) If there are any questions please let us know! Many thanks! Natasha [1] https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-lang= uage/ [2] https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nroon= ey@gsm.org On 22 Jul 2016, at 11:39, Natasha Rooney > wrote: Hi all, Thanks for the meeting this week. We are pleased to announce that both draf= ts below have entered into Working Group Last Call. We will aim to exit WGL= C on 12th August, which gives us three week from today. draft-ietf-slim-multilangcontent-01 Multiple Language Content Type draft-ietf-slim-negotiating-human-language-01 Negotiating Human Language in Real-Time Communications Issues: if you have issues please submit these to the IETF Issue Tracker at= [1]. Please feel free to discuss items on the list also. Thanks everyone! Natasha [1] https://tools.ietf.org/wg/slim/trac/newticket Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_50CFEBF2EF1A47209781BE4FC34BAD7Fgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

The chairs have reviewed the tickets we currently have and = have asked the author to make edits where necessary. All the tickets we had= were for the draft-ietf-slim-negotiating-human-language-04 draft. This mea= ns we likely have not had the required number of reviewers for the draft-ietf-slim-multilangcontent-04[2] draft. = Therefore, here are the actions and next steps.

  • ACTION: Randall, please take a look at the= comments on the tickets and make changes where necessary.
  • ACTION: All,= please review the draft-ietf-slim-multilangcontent-04[2] draft, and s= end tickets if changes are needed
    • Please also let us know you have read it, as then we know ho= w many reviewers there have been.
  • NEXT STEP: After changes have been ma= de, Bernard will start pushing the document through the RFC process (reques= ting AD reviews etc.) 

If there are any questions please let us know! Many thanks!

Natasha

[1] https://datatracker.ietf.org/doc/draft-ie= tf-slim-negotiating-human-language/ 
[2] https://datatracker.ietf.org/doc/draft-ietf-slim-mu= ltilangcontent/

Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 77= 30 219 765 | @thisNatasha | Skype: nrooney@gsm.org


On 22 Jul 2016, at 11:39, Natasha Rooney <nrooney@gsma.com> wrote:

Hi all,

Thanks for the meeting this week. We are pleased to announc= e that both drafts below have entered into Working Group Last Call. We will= aim to exit WGLC on 12th August, which gives us three week from today.&nbs= p;

draft-ietf-slim-multilangcontent-01 
Multiple Language Content Type

draft-ietf-slim-negotiating-human-language-01 
Negotiating Human Language in Real-Time Communications

Issues: if you have issues please submit = these to the IETF Issue Tracker at [1]. Please feel free to discuss items o= n the list also. 

Thanks everyone!

Natasha

[1] https://tools.ietf.org/wg/slim/trac/newticket

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com=  | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org


This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

--_000_50CFEBF2EF1A47209781BE4FC34BAD7Fgsmacom_-- From nobody Mon Aug 15 11:49:33 2016 Return-Path: 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 D84E612B065; Mon, 15 Aug 2016 11:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 lfDlqTv_PmpK; Mon, 15 Aug 2016 11:49:30 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFDE12B01D; Mon, 15 Aug 2016 11:49:30 -0700 (PDT) Received: from [10.143.98.115] (127.0.0.1) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 15 Aug 2016 11:49:29 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Randall Gellens (IETF)" X-Mailer: iPad Mail (13F69) In-Reply-To: <082.6d57eb8e8eac2bdfb6e935743d5efdd8@tools.ietf.org> Date: Mon, 15 Aug 2016 19:49:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3BDD835A-BDF0-42DC-A25A-0626DA4B5749@randy.pensive.org> References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.6d57eb8e8eac2bdfb6e935743d5efdd8@tools.ietf.org> To: slim issue tracker Archived-At: Cc: slim@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:49:32 -0000 Since we're talking about a flag to indicate the origination's preference to= the answerer, which is advisory in all cases, I don't see that it makes any= difference which is the default. --Randall Sent from my iPad > On Aug 15, 2016, at 5:54 PM, slim issue tracker = wrote: >=20 > #7: The notation for Advisory vs Required is not logical and needs revisio= n >=20 >=20 > Comment (by nrooney@gsma.com): >=20 > Chairs: Randall - can you respond to this when you have a chance? It seems= > like there are some interesting points here which should be discussed on- > list (e.g. the default value perhaps should change). >=20 > --=20 > -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-slim- > gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org= > Type: defect | Status: new > Priority: major | Milestone: > Component: negotiating-human- | Version: > language | Resolution: > Severity: In WG Last Call | > Keywords: reject | > -------------------------------------+------------------------------------= - >=20 > Ticket URL: > slim >=20 From nobody Mon Aug 15 12:14:28 2016 Return-Path: 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 0791612D135 for ; Mon, 15 Aug 2016 12:14:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 xX-DePyeaM2L for ; Mon, 15 Aug 2016 12:14:23 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A97D12B053 for ; Mon, 15 Aug 2016 12:14:23 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x25so25355553qtx.2 for ; Mon, 15 Aug 2016 12:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6eJpjFdhM7d3ifSBv2OeZPNBjorbML5wL/uaG4wP4iw=; b=Bf+XfPzEN6/VL2zxxptrooKirhI0NehzziIGff9z4ctmxqhdO0FrKclFf80rtU0J2+ Urn/WNMEbAf053n3izT/Qkh4ZQUgNstVMbf62Pvx3aiH4MZbyCNQqIxFNIG3MqXIH5Oj qrU0Y+1/mXOfGCsId0CLGFUe/Wc7r9vTRQkhwTrJqAG3NpUw/W+qCABKZgiQOpQzx3lR h0v8+uvoQSABLI08lEXjNlaQXOrfVmg0ap1VhsM2b1tY9H8ZCu/J0XQB0xl4bf7qc/KQ kX37Rj6vk9GLSCvDUl3Lm97zQyKtsRVc2lSVJTr+Ofq2wxrj87AsRpQzVuIUf2wMxRJc vqnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6eJpjFdhM7d3ifSBv2OeZPNBjorbML5wL/uaG4wP4iw=; b=l9fu/d1cCb8NaCdWXk8bIeLtITARjtCcI1XRsNhrgpBTuwN5ewOiWAHbq7iZydZf55 0c18JNXIZnkouNYVsPAu9ibnpRT6+t89D8SRHOtrXOQ6n6gpFMraTR9ETo/t5wuvosO1 wgTxT1YIqQLdsc7hQfQZyPI9P2zPNCD3wSDuNj8m4BgFawhtVcCzddpHAnIgzNdMsdq0 /a5JQd3GFno4KTx0J+KHdqeFl+CdzindFC4J/8WN8Gl+V9zK7s/1D5uaf7K2vNTnMtGK UY3BlyQYSjlEL4t2xA32hjqVIJkHPtUkRbEjHYKBO8HoSUjmNDgrhA/DW3g5esPOSjn7 Z4IQ== X-Gm-Message-State: AEkoouuB565G7PA/9KPnOaoWv09C5/jx1GC/C3sMspOY9ZB0ZuU7R6Jri0n4O/wFu6Rv/g== X-Received: by 10.200.50.199 with SMTP id a7mr34549550qtb.43.1471288462301; Mon, 15 Aug 2016 12:14:22 -0700 (PDT) Received: from [10.0.1.9] (dynamic-acs-24-154-119-181.zoominternet.net. [24.154.119.181]) by smtp.gmail.com with ESMTPSA id x185sm11896832qkb.14.2016.08.15.12.14.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 12:14:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <3BDD835A-BDF0-42DC-A25A-0626DA4B5749@randy.pensive.org> Date: Mon, 15 Aug 2016 15:14:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E07FF97-E779-4DE5-8819-51BF11603B52@brianrosen.net> References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.6d57eb8e8eac2bdfb6e935743d5efdd8@tools.ietf.org> <3BDD835A-BDF0-42DC-A25A-0626DA4B5749@randy.pensive.org> To: "Randall Gellens (IETF)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim issue tracker , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , Natasha Rooney Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 19:14:25 -0000 I agree, and think the asterisk naturally means =E2=80=9Call=E2=80=9D = and thus the suggested default is correct. As was noted, we should probably just drop the reference to = Accept-Language, since it uses an entirely different syntax. Brian > On Aug 15, 2016, at 2:49 PM, Randall Gellens (IETF) = wrote: >=20 > Since we're talking about a flag to indicate the origination's = preference to the answerer, which is advisory in all cases, I don't see = that it makes any difference which is the default. >=20 > --Randall >=20 > Sent from my iPad >=20 >> On Aug 15, 2016, at 5:54 PM, slim issue tracker = wrote: >>=20 >> #7: The notation for Advisory vs Required is not logical and needs = revision >>=20 >>=20 >> Comment (by nrooney@gsma.com): >>=20 >> Chairs: Randall - can you respond to this when you have a chance? It = seems >> like there are some interesting points here which should be discussed = on- >> list (e.g. the default value perhaps should change). >>=20 >> --=20 >> = -------------------------------------+------------------------------------= - >> Reporter: | Owner: draft-ietf-slim- >> gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: negotiating-human- | Version: >> language | Resolution: >> Severity: In WG Last Call | >> Keywords: reject | >> = -------------------------------------+------------------------------------= - >>=20 >> Ticket URL: = >> slim >>=20 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Mon Aug 15 12:31:14 2016 Return-Path: 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 3ACC212D512; Mon, 15 Aug 2016 12:31:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 XIpw5nUrEwdm; Mon, 15 Aug 2016 12:31:10 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F812D500; Mon, 15 Aug 2016 12:31:10 -0700 (PDT) Received: from [10.79.0.197] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 15 Aug 2016 12:31:09 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E07FF97-E779-4DE5-8819-51BF11603B52@brianrosen.net> References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.6d57eb8e8eac2bdfb6e935743d5efdd8@tools.ietf.org> <3BDD835A-BDF0-42DC-A25A-0626DA4B5749@randy.pensive.org> <5E07FF97-E779-4DE5-8819-51BF11603B52@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Mon, 15 Aug 2016 12:31:04 -0700 To: Brian Rosen From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim issue tracker , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Natasha Rooney Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 19:31:12 -0000 Yes, deleting the mention of Accept-Language is good. At 3:14 PM -0400 8/15/16, Brian Rosen wrote: > I agree, and think the asterisk naturally means "all" and thus the > suggested default is correct. > > As was noted, we should probably just drop the reference to > Accept-Language, since it uses an entirely different syntax. > > Brian > >> On Aug 15, 2016, at 2:49 PM, Randall Gellens (IETF) >> wrote: >> >> Since we're talking about a flag to indicate the origination's >> preference to the answerer, which is advisory in all cases, I >> don't see that it makes any difference which is the default. >> >> --Randall >> >> Sent from my iPad >> >>> On Aug 15, 2016, at 5:54 PM, slim issue tracker >>> wrote: >>> >>> #7: The notation for Advisory vs Required is not logical and needs revision >>> >>> >>> Comment (by nrooney@gsma.com): >>> >>> Chairs: Randall - can you respond to this when you have a chance? It seems >>> like there are some interesting points here which should be discussed on- >>> list (e.g. the default value perhaps should change). >>> >>> -- >>> -------------------------------------+------------------------------------- >>> Reporter: | Owner: draft-ietf-slim- >>> gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: negotiating-human- | Version: >>> language | Resolution: >>> Severity: In WG Last Call | >>> Keywords: reject | >>> -------------------------------------+------------------------------------- >>> >>> Ticket URL: >>> slim >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Deregulation will be the greatest thing to happen to the airlines since the jet engine. -- Richard Ferris, CEO United Airlines, 1976 From nobody Mon Aug 15 14:47:47 2016 Return-Path: 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 C521D12B02A; Mon, 15 Aug 2016 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 1hKKXBPj941F; Mon, 15 Aug 2016 14:47:44 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B4812D511; Mon, 15 Aug 2016 14:47:38 -0700 (PDT) Received: from localhost ([::1]:46560 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZPjN-0003hx-MF; Mon, 15 Aug 2016 14:47:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-multilangcontent@ietf.org, doug@ewellic.org X-Trac-Project: slim Date: Mon, 15 Aug 2016 21:47:37 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/11 Message-ID: <056.2b11befad03603f2a3c590e5d3b5ae48@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, doug@ewellic.org, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-multilangcontent@ietf.org Resent-Message-Id: <20160815214738.29B4812D511@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 14:47:38 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #11 (multilangcontent): Remove buzzword X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:47:46 -0000 #11: Remove buzzword The Introduction says, "the need to communicate efficiently with little margin for miscommunication has grown exponentially." "Exponentially" in this context is a hyperbolic buzzword, is usually difficult to prove, and may cause readers to tune out or disregard other claims. Suggest replacing "exponentially" with "significantly." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-slim- doug@ewellic.org | multilangcontent@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: | Version: multilangcontent | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: slim From nobody Mon Aug 15 14:53:54 2016 Return-Path: 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 C551C12D1B9; Mon, 15 Aug 2016 14:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 OTZZthjxCV4C; Mon, 15 Aug 2016 14:53:51 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4398B12B020; Mon, 15 Aug 2016 14:53:51 -0700 (PDT) Received: from localhost ([::1]:46721 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZPpO-0004gJ-Ur; Mon, 15 Aug 2016 14:53:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-multilangcontent@ietf.org, doug@ewellic.org X-Trac-Project: slim Date: Mon, 15 Aug 2016 21:53:50 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/12 Message-ID: <056.e854dcc7b4f5db3d3cbd8376701cd071@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, doug@ewellic.org, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-multilangcontent@ietf.org Resent-Message-Id: <20160815215351.4398B12B020@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 14:53:51 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #12 (multilangcontent): Consider removing health warning about short tags X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:53:53 -0000 #12: Consider removing health warning about short tags Section 5 includes a paragraph warning the user to use only a primary language subtag and no additional subtags "unless the languages might be mutually incomprehensible without them." RFC 5646, Section 4.1 already advises producers of language tags to "tag content wisely" and not include unnecessary subtags. On occasion there may be valid reasons for additional subtags, such as to indicate script for text content, and this additional warning could cause users to underspecify the tag at the expense of usability. Suggest removing this paragraph. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-slim- doug@ewellic.org | multilangcontent@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: | Version: multilangcontent | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: slim From nobody Mon Aug 15 14:55:27 2016 Return-Path: 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 D9CB912D558; Mon, 15 Aug 2016 14:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 6JmPqtVPn-0l; Mon, 15 Aug 2016 14:55:24 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8365712B020; Mon, 15 Aug 2016 14:55:24 -0700 (PDT) Received: from localhost ([::1]:46790 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZPqu-0004nu-3E; Mon, 15 Aug 2016 14:55:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, doug@ewellic.org X-Trac-Project: slim Date: Mon, 15 Aug 2016 21:55:24 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/13 Message-ID: <056.81db4002152ba25565a5ef29c43cc8d1@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, doug@ewellic.org, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815215524.8365712B020@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 14:55:24 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #13 (negotiating-human-language): Consider removing health warning about short tags X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:55:26 -0000 #13: Consider removing health warning about short tags Section 6.2 includes a paragraph warning the user to use only a primary language subtag and no additional subtags "unless the languages might be mutually incomprehensible without them." RFC 5646, Section 4.1 already advises producers of language tags to "tag content wisely" and not include unnecessary subtags. On occasion there may be valid reasons for additional subtags, such as to indicate script for text content, and this additional warning could cause users to underspecify the tag at the expense of usability. Suggest removing this paragraph. -- -------------------------------------+------------------------------------- Reporter: doug@ewellic.org | Owner: draft-ietf-slim- Type: enhancement | negotiating-human-language@ietf.org Priority: minor | Status: new Component: negotiating-human- | Milestone: language | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 14:58:22 2016 Return-Path: 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 1581212D522; Mon, 15 Aug 2016 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 9NKaWsPOl8CZ; Mon, 15 Aug 2016 14:58:20 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9500512D11C; Mon, 15 Aug 2016 14:58:20 -0700 (PDT) Received: from localhost ([::1]:46923 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZPtk-00061z-9j; Mon, 15 Aug 2016 14:58:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, doug@ewellic.org X-Trac-Project: slim Date: Mon, 15 Aug 2016 21:58:20 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/14 Message-ID: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, doug@ewellic.org, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815215820.9500512D11C@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 14:58:20 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #14 (negotiating-human-language): Expand acronyms X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:58:22 -0000 #14: Expand acronyms From Section 3, "Expected Use": "This facility may be used by NENA and 3GPP. NENA has already referenced it in NENA 08-01 (i3 Stage 3 version 2) in describing attributes of calls presented to an ESInet, and may add further details in that or other documents. 3GPP may reference this mechanism in general call handling and emergency call handling. Some CRs introduced in SA1 have anticipated this functionality being provided within SDP." None of NENA, 3GPP, ESINet, CR, or SA1 is defined or expanded in this document. Suggest expanding the acronyms for the benefit of readers who may not be familiar with these terms (SDP should be well known to all readers). -- -------------------------------------+------------------------------------- Reporter: doug@ewellic.org | Owner: draft-ietf-slim- Type: enhancement | negotiating-human-language@ietf.org Priority: minor | Status: new Component: negotiating-human- | Milestone: language | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 15:00:46 2016 Return-Path: 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 A71ED12D522; Mon, 15 Aug 2016 15:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 aREVbX472y1b; Mon, 15 Aug 2016 15:00:43 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6860612B020; Mon, 15 Aug 2016 15:00:43 -0700 (PDT) Received: from localhost ([::1]:46987 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZPw3-0006KE-2j; Mon, 15 Aug 2016 15:00:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, doug@ewellic.org X-Trac-Project: slim Date: Mon, 15 Aug 2016 22:00:43 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/15 Message-ID: <056.8b2a1813510dca221e0c387153891786@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, doug@ewellic.org, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815220043.6860612B020@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 15:00:43 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: [Slim] [slim] #15 (negotiating-human-language): Refer to BCP 47 instead of RFC 5646 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 22:00:45 -0000 #15: Refer to BCP 47 instead of RFC 5646 Section 6 says, "The attribute value should be a language tag per RFC 5646 [RFC5646]". Suggest replacing "RFC 5646" with "BCP 47" in all such references (also in multilangcontent) unless a specific section number is cited. -- -------------------------------------+------------------------------------- Reporter: doug@ewellic.org | Owner: draft-ietf-slim- Type: enhancement | negotiating-human-language@ietf.org Priority: minor | Status: new Component: negotiating-human- | Milestone: language | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 15:16:01 2016 Return-Path: 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 79BF012D73A; Mon, 15 Aug 2016 15:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 qoHRl0j19wyy; Mon, 15 Aug 2016 15:15:57 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FDC12D5F4; Mon, 15 Aug 2016 15:15:57 -0700 (PDT) Received: from localhost ([::1]:47418 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZQAj-0000Wo-4s; Mon, 15 Aug 2016 15:15:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, gunnar.hellstrom@omnitor.se X-Trac-Project: slim Date: Mon, 15 Aug 2016 22:15:53 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/5#comment:2 Message-ID: <082.b565985e4bd54b80e199d0ec927ad87c@tools.ietf.org> References: <067.dddc6438e41ce7624872be9398d943d7@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <067.dddc6438e41ce7624872be9398d943d7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, gunnar.hellstrom@omnitor.se, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815221557.C3FDC12D5F4@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 15:15:57 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #5 (negotiating-human-language): Improve paragraph on relay services in section 1. Introduction. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 22:16:00 -0000 #5: Improve paragraph on relay services in section 1. Introduction. Comment (by gunnar.hellstrom@omnitor.se): Yes, this might have become a bit too detailed. But the original text started with a false assumption that we should avoid. It assumed that the relay service would serve just one language pair, as is currently the case often in USA. ( but in fact not, most relay services have both English and Spanish support ). Relay services can instead be developed to be multi-language services, having benefit of the humintlang indications. Since this is just an informational section, we could decrease its size to e.g. -------------------------------------------------------------------------------- Regarding relay services, in the case of an emergency call requiring sign language, there are a number of approaches that can be enhanced by having the language and modality preferences specified by the caller and conveyed to the relay service or the service provider or the emergency service network and PSAP. The need for language and modality indication becomes extra apparent when dealing with emergency calls by visitors to regions with other default languages than the caller's. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: relay services | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 15:24:54 2016 Return-Path: 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 0D82E12D5C6; Mon, 15 Aug 2016 15:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 C-6hWAeJOzhI; Mon, 15 Aug 2016 15:24:50 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCEC12D5C5; Mon, 15 Aug 2016 15:24:50 -0700 (PDT) Received: from localhost ([::1]:47636 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZQJK-0007T2-L7; Mon, 15 Aug 2016 15:24:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "slim issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com X-Trac-Project: slim Date: Mon, 15 Aug 2016 22:24:46 -0000 X-URL: https://tools.ietf.org/slim/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:3 Message-ID: <082.d896677e66d587978eec9fa9a8a18c24@tools.ietf.org> References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, nrooney@gsma.com, slim@ietf.org X-SA-Exim-Mail-From: trac+slim@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org Resent-Message-Id: <20160815222450.9CCEC12D5C5@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 15:24:50 -0700 (PDT) Resent-From: trac+slim@tools.ietf.org Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 22:24:52 -0000 #7: The notation for Advisory vs Required is not logical and needs revision Comment (by gunnar.hellstrom@omnitor.se): By having the default value to be to reject the call, that is very seldom desired, the usage very often will be that the user (= sdp encoder ) will need to remember to insert the notation for "do not reject" in most SDPs. That seems awkward and a bit risky. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-slim- gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: negotiating-human- | Version: language | Resolution: Severity: In WG Last Call | Keywords: reject | -------------------------------------+------------------------------------- Ticket URL: slim From nobody Mon Aug 15 15:42:47 2016 Return-Path: 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 13BBE12D791 for ; Mon, 15 Aug 2016 15:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 JnsQbTMnkGjT for ; Mon, 15 Aug 2016 15:42:43 -0700 (PDT) Received: from bin-vsp-out-03.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 EE3E512D780 for ; Mon, 15 Aug 2016 15:42:42 -0700 (PDT) X-Halon-ID: 90610306-6339-11e6-88cf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.27.222]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 16 Aug 2016 00:42:36 +0200 (CEST) To: slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org, bernard_aboba@hotmail.com, nrooney@gsma.com References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> <082.520d809e30eb25bc269a57493a32061e@tools.ietf.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 16 Aug 2016 00:42:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <082.520d809e30eb25bc269a57493a32061e@tools.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 22:42:46 -0000 It must be a mistake to close #6 saying that it is a summary. It is #10 that is a summary and can be closed. Please revive #6. It collects information on modality that was spread in various sections and was treated quite informally. It also adds information. /Gunnar Den 2016-08-15 kl. 19:00, skrev slim issue tracker: > #6: Collect information on modality in separate section for clarity > > Changes (by nrooney@gsma.com): > > * status: new => closed > * resolution: => invalid > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Aug 15 16:03:38 2016 Return-Path: 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 482D112D54D for ; Mon, 15 Aug 2016 16:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 wTqMYwnmljdG for ; Mon, 15 Aug 2016 16:03:36 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 66FC012D51D for ; Mon, 15 Aug 2016 16:03:35 -0700 (PDT) X-Halon-ID: 7a8d2493-633c-11e6-88cf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.27.222]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 16 Aug 2016 01:03:28 +0200 (CEST) To: slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org, bernard_aboba@hotmail.com References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> <082.b0f475e92bf8ec7091bbbead2cf1f80e@tools.ietf.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <42b13ebf-863b-9f7d-b0b4-6ed5ffd8ec17@omnitor.se> Date: Tue, 16 Aug 2016 01:03:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <082.b0f475e92bf8ec7091bbbead2cf1f80e@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 23:03:37 -0000 Den 2016-08-15 kl. 18:50, skrev slim issue tracker: > #6: Collect information on modality in separate section for clarity > > > Comment (by bernard_aboba@hotmail.com): > > I'm a bit confused by the meaning of "modality parameter". Are you > proposing that an assumption be made about language if signing is not > explicitly indicated? For example, if there is no language indicated for a > video m-line, or just "English" (but not ASL), what should we assume "by > default"? The most important need for the modality parameter is to tell in media sections for a media that has no explicit modality, ( like m=application ) in what modality the language is supposed to be used. In WebRTC, we will have real-time text multiplexed in a subchannel of a data channel. There is no m=text there, so we need to apply a parameter saying that the language is used in written modality. So, normally the modality parameter goes together with a list of languages intended to be used in that modality in that media in a specified direction. What you ask about is probably a side effect I have thought about for a long time and introduced here. It is that it in many cases can be sufficient to indicate that a specific modality is preferred, and the language is given by being default for the service or the country. That is why all languages are optional in the language list in the proposed syntax. This side effect may be seen as a complication and could be deleted, saying that you must always indicate at least one language in a humintlang attribute. There are joint text and sign language relay services which currently start with asking their users if they want to use text or sign language ( they serve total conversation users ). But they might only serve one language area with one written language and one sign language. This extra question could be eliminated if the terminal indicated the intended modality, and no language because it is a default for that service. /Gunnar > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Aug 15 17:05:53 2016 Return-Path: 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 DD4CB12D7B0 for ; Mon, 15 Aug 2016 17:05:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 uAw9DUjjkSOd for ; Mon, 15 Aug 2016 17:05:49 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9367412D532 for ; Mon, 15 Aug 2016 17:05:49 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id x25so28250076qtx.2 for ; Mon, 15 Aug 2016 17:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=In7GImuDoFp2RuhqJAoBAhunTSNpdOkRQNMDuqL8kh4=; b=ShEBnpvMc0ToOBTLQtCRgUY82IoAuP3tfEJJpqtagYzFwQPiMpZ8/ekGDo6ZW/uNu+ F5izm4TezdcmCwc4rdEKz1kX2Vw0PjHbZknzYr6K6JJiVVb1b4ttQa+7dLep2yRVv6iX Q5qH/4k9A1wEFqbeQ+TA75pd6WrkgDyEHHQt8h4bXd4jy4v9UZa6l6wfaXaiDr4Ytejj p2ZtDIuvohqhtzU9LdiGdAYqSdCwaNumSkhXEBlA46nqsgx/X9DfLsX17S2eMJhltRNL hWpF+zA/H68VZBQPKI+47nDv+mkq+G2/rPIvZpIu69edzB6eIk/weDo+xKuO3WPjtayS vDyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=In7GImuDoFp2RuhqJAoBAhunTSNpdOkRQNMDuqL8kh4=; b=mwopo0kNaQWpqFNtofUC/TngBtZawmgPrhWqgg9HX/kkrxY+/hhHKN+wfsWve29MCR OvbvK6L7Lngrtmk3WF9vwWDpvLBNoGqe6hJsFiShc3wlwOqzvNdYifGXod0b3KQDYvwq jOTPzvZEpRinUTwBySXjdE58w4ePygy6YuyKGXJzJjxnmGz+VP3o6gDXXPjnbF7XyzYv TycUEVBYzO0XZk2F7zM2EvzwMF/UmRStHLX5dUxf2vr3Xpu39iblZy/jGpjindZ6leEz TcF5UMRceC0ATy4jItzh4CaXnL+qE6kcfG+yu2rA2AUEVN2JinaxWXMMCQ+2OEf+ykkj 4QgA== X-Gm-Message-State: AEkoous5R/zdQIvrhw1BAnTXeRpNLZXKyLf9Vkfp6yAzNUOCLRPkWIPDMFrUURycr7+avQ== X-Received: by 10.237.59.161 with SMTP id r30mr35791320qte.22.1471305948769; Mon, 15 Aug 2016 17:05:48 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 22sm13729835qtw.21.2016.08.15.17.05.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 17:05:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <082.d896677e66d587978eec9fa9a8a18c24@tools.ietf.org> Date: Mon, 15 Aug 2016 20:05:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.d896677e66d587978eec9fa9a8a18c24@tools.ietf.org> To: slim issue tracker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 00:05:52 -0000 You say =E2=80=9Cvery seldom desired=E2=80=9D, but I=E2=80=99m not = convinced that is the case. It might be true, but for a whole lot of = cases, if you can=E2=80=99t communicate, then you either need to change = your request, or try a different service. Brian > On Aug 15, 2016, at 6:24 PM, slim issue tracker = wrote: >=20 > #7: The notation for Advisory vs Required is not logical and needs = revision >=20 >=20 > Comment (by gunnar.hellstrom@omnitor.se): >=20 > By having the default value to be to reject the call, that is very = seldom > desired, the usage very often will be that the user (=3D sdp encoder ) = will > need to remember to insert the notation for "do not reject" in most = SDPs. > That seems awkward and a bit risky. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-slim- > gunnar.hellstrom@omnitor.se | = negotiating-human-language@ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: negotiating-human- | Version: > language | Resolution: > Severity: In WG Last Call | > Keywords: reject | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: = > slim >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Tue Aug 16 00:46:12 2016 Return-Path: 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 12B2C12D0D8 for ; Tue, 16 Aug 2016 00:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 OtpPTIGRkjxH for ; Tue, 16 Aug 2016 00:46:08 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 9D44D12D0DC for ; Tue, 16 Aug 2016 00:46:05 -0700 (PDT) X-Halon-ID: 7ad974dc-6385-11e6-be68-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.27.222]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 16 Aug 2016 09:46:02 +0200 (CEST) To: Brian Rosen , slim issue tracker References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.d896677e66d587978eec9fa9a8a18c24@tools.ietf.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 16 Aug 2016 09:45:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org, Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 07:46:11 -0000 Den 2016-08-16 kl. 02:05, skrev Brian Rosen: > You say “very seldom desiredâ€, but I’m not convinced that is the case. It might be true, but for a whole lot of cases, if you can’t communicate, then you either need to change your request, or try a different service. Yes, I agree that it is hard to say how the "reject if no match" parameter will be used. In recent discussions it was said that there was risk for the users having common ways to communicate that they had not bothered configuring in their devices and therefore getting calls rejected that could have been performed. E.g. neighbour languages. But the other way around is also annoying and frustrating; to get a call accepted, and then after some efforts to find a way to communicate, you need to give up without even being able to say "sorry, we cannot understand each other, so bye". So, yes, both values of this parameter has its values and risks and it is hard to know how it will be used. It is a session level parameter and with good definition and syntax, the default could be either way. I have a slight preference for "don't reject" as the default because it has a lower risk for wanted calls to be rejected. /Gunnar > > Brian >> On Aug 15, 2016, at 6:24 PM, slim issue tracker wrote: >> >> #7: The notation for Advisory vs Required is not logical and needs revision >> >> >> Comment (by gunnar.hellstrom@omnitor.se): >> >> By having the default value to be to reject the call, that is very seldom >> desired, the usage very often will be that the user (= sdp encoder ) will >> need to remember to insert the notation for "do not reject" in most SDPs. >> That seems awkward and a bit risky. >> >> -- >> -------------------------------------+------------------------------------- >> Reporter: | Owner: draft-ietf-slim- >> gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: negotiating-human- | Version: >> language | Resolution: >> Severity: In WG Last Call | >> Keywords: reject | >> -------------------------------------+------------------------------------- >> >> Ticket URL: >> slim >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > _______________________________________________ > 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 From nobody Tue Aug 16 03:55:58 2016 Return-Path: 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 7E14C12D75C for ; Tue, 16 Aug 2016 03:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=hNztoQ4o; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=fI82tUc8 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 i3dLz8x_l9wt for ; Tue, 16 Aug 2016 03:55:49 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D268512D67D for ; Tue, 16 Aug 2016 03:55:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 45DA3204A2 for ; Tue, 16 Aug 2016 06:55:48 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 16 Aug 2016 06:55:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Bsn+gkrWVn34qjvfnef+CkTn8XE=; b=hNztoQ 4o0hmEXhgfJzZQNIE0VbcjgHxsQlZqjfANG6YBULziiKOJZCjoZAIrZgIKYdvVuP y+CxNhE027LVBe8pUt0mB/9pcD//AEK1FPCGFexI/0pzmOEzIWCWdy1H/6t0bMVx KYDG9Amd4QX41UriH6FnPSbw1aPrxwac1+Gpk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Bsn+gkrWVn34qjv fnef+CkTn8XE=; b=fI82tUc8/UKWUteFczZNmD+HqloiKHQ8de+G6gZrZ0XF3YG eHeG2gF65bvmqBxlDjOLxu8jYPwweifRcs/5pxqoHTNbQDLoZwK0lHVo2uFV2H7H 5QRJCNzPj/HRzabhWr+Vk4CeZkSp1nIFKXyQnDf4nNV2BWhmNKeb2OJhmN3w= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0AA86966B6; Tue, 16 Aug 2016 06:55:48 -0400 (EDT) Message-Id: <1471344947.2545363.696694081.777D8CAE@webmail.messagingengine.com> X-Sasl-Enc: /rMIJc9T+rpUf0FzX+5YHApjXuCLpXeTR+W63MWycO7r 1471344947 From: Alexey Melnikov To: slim@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147134494725453630"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-71d1d584 Date: Tue, 16 Aug 2016 11:55:47 +0100 In-Reply-To: <50CFEBF2-EF1A-4720-9781-BE4FC34BAD7F@gsma.com> References: <56128392-5138-487C-9D99-151BC4C13D34@gsma.com> <50CFEBF2-EF1A-4720-9781-BE4FC34BAD7F@gsma.com> Archived-At: Subject: [Slim] Early AD review of draft-ietf-slim-multilangcontent-04.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 10:55:56 -0000 This is a multi-part message in MIME format. --_----------=_147134494725453630 Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi, Hopefully this will help the discussion: In Section 3.2, message/global needs a reference (RFC 6532). In Section 4, 2nd para: you are restating a requirement from MIME. Don't use RFC 2119 keywords here. In Section 8 (all examples in subsections): From/To header fields must include email addresses in order to be syntactically correct. In Section 11: you need to use the official Media Type registration template from RFC 6838. On Mon, Aug 15, 2016, at 06:12 PM, Natasha Rooney wrote: > Hi all, > > The chairs have reviewed the tickets we currently have and have asked > the author to make edits where necessary. All the tickets we had were > for the draft-ietf-slim-negotiating-human-language-04 draft. This > means we likely have not had the required number of reviewers for the > draft-ietf-slim-multilangcontent-04[2] draft. Therefore, here are the > actions and next steps. > > * *ACTION:* Randall, please take a look at the comments on the > tickets and make changes where necessary. > * *ACTION: All*, please review the draft-ietf-slim-multilangcontent- > 04[2] draft, and send tickets if changes are needed > * Please also let us know you have read it, as then we know how > many reviewers there have been. > * *NEXT STEP: *After changes have been made, Bernard will start > pushing the document through the RFC process (requesting AD reviews > etc.) > > If there are any questions please let us know! Many thanks! > > Natasha > > [1] https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > [2] https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > Natasha Rooney | Internet Engineering Director | GSMA | > nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: > nrooney@gsm.org > > >> On 22 Jul 2016, at 11:39, Natasha Rooney wrote: >> >> Hi all, >> >> Thanks for the meeting this week. We are pleased to announce that >> both drafts below have entered into Working Group Last Call. We >> will aim to exit WGLC on 12th August, which gives us three week >> from today. >> >> draft-ietf-slim-multilangcontent-01 >> Multiple Language Content Type >> >> draft-ietf-slim-negotiating-human-language-01 >> Negotiating Human Language in Real-Time Communications >> >> *Issues: *if you have issues please submit these to the IETF Issue >> Tracker at [1]. Please feel free to discuss items on the list also. >> >> Thanks everyone! >> >> Natasha >> >> [1] https://tools.ietf.org/wg/slim/trac/newticket >> >> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | >> nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: >> nrooney@gsm.org >> >> >> This email and its attachments are intended for the above named only >> and may be confidential. If they have come to you in error you must >> take no action based on them, nor must you copy or show them to >> anyone; please reply to this email or call +44 207 356 0600 and >> highlight the error. >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > This email and its attachments are intended for the above named only > and may be confidential. If they have come to you in error you must > take no action based on them, nor must you copy or show them to > anyone; please reply to this email or call +44 207 356 0600 and > highlight the error. > _________________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --_----------=_147134494725453630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html 
Hi,
Hopefully this will help the discussion:

In Section 3.2, message/global needs a reference (RFC 6532).

In Section 4, 2nd para: you are restating a requirement from MIME. Don't us= e RFC 2119 keywords here.

In Section 8 (all examples in subsections): From/To header fields must incl= ude email addresses in order to be syntactically correct.

In Section 11: you need to use the official Media Type registration templat= e from RFC 6838.


On Mon, Aug 15, 2016, at 06:12 PM, Natasha Rooney wrote:
Hi all,

The chairs have reviewed the tickets we currently have and have asked = the author to make edits where necessary. All the tickets we had were for t= he draft-ietf-slim-negotiating-human-language-04 draft. This means we likel= y have not had the required number of reviewers for the draft-ietf-slim-multilangcontent-04[2] draft. = Therefore, here are the actions and next steps.

  • ACTION: Randall, please take a look at the comments on = the tickets and make changes where necessary.
  • ACTION: <= span class=3D"colour" style=3D"color:rgb(255, 38, 0)">All, pleas= e review the draft-ietf-slim-multilangcontent-04[2] draft, and send ti= ckets if changes are needed
    • Please also let us know you have read it, as then we know how many = reviewers there have been.
  • NEXT STEP: After ch= anges have been made, Bernard will start pushing the document through the R= FC process (requesting AD reviews etc.) 

If t= here are any questions please let us know! Many thanks!

Natasha


Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nro= oney@gsm.org


On 22 Jul 2016, at 11:39, Natasha Roone= y <nrooney@gsma.com> wrote:

Hi all,

Thanks for the meeting this week. We are pleased to announce that= both drafts below have entered into Working Group Last Call. We will aim t= o exit WGLC on 12th August, which gives us three week from today.

draft-ietf-slim-multilangcontent-01 
Multiple Language Content Type

draft-ietf-slim-negotiating-human-language-01 
Negotiating Human Language in Real-Time Communications

Issues: if you have issues please submit these to the IETF Issu= e Tracker at [1]. Please feel free to discuss items on the list also. =

Thanks everyone!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF = | GSMA | nrooney@gsma.com = ;| +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org


Th= is email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

_______________________________________________
SLIM mailing list
https://www.ietf.org/mailman/listinfo/slim

Th= is email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

_______________________________________________
SLIM mailing list

--_----------=_147134494725453630-- From nobody Tue Aug 16 14:19:16 2016 Return-Path: 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 C444612D74E for ; Tue, 16 Aug 2016 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 lF_1YnOV5d9n for ; Tue, 16 Aug 2016 14:19:12 -0700 (PDT) Received: from bin-vsp-out-03.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 2FA7E12D0AB for ; Tue, 16 Aug 2016 14:19:12 -0700 (PDT) X-Halon-ID: 10ecc229-63f7-11e6-88cf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 16 Aug 2016 23:19:07 +0200 (CEST) To: Brian Rosen , slim issue tracker References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.6cbababa93e825f163e92644f6e9d826@tools.ietf.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 16 Aug 2016 23:19:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------684F9DD1193203BE96EAB5C6" Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:19:16 -0000 This is a multi-part message in MIME format. --------------684F9DD1193203BE96EAB5C6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-08-09 kl. 15:01, skrev Brian Rosen: > I am not in favor of this change. I think the existing text is fine. > > Brian The described function for advisory vs required in the draft is a session level function. That makes the coding very unusual when it is said that it can be attached to any media level language indication. I do not think that that kind of logic behind the coding is acceptable in an IETF document. If you are really eager to keep the current syntax, we would need to add some media level semantics to the "don't reject" parameter. That is to give a specific meaning of which media, language and direction the parameter is tacked on to. A possible coding would be to let the tacked on character indicate that the language it is tacked on to is the most favoured language. There are two possible characters indicating two proposed dispositions in case of no match in the whole sdp. "*" marks a most favoured language and that the call should be connected even if no language match was found in the whole sdp. "+" marks a most favoured language and that the call should be rejected if no language match was found in the whole sdp. It is most common to only have one most favoured language per direction, but it is allowed to use the indication for two languages in different modalities for the same direction if the user is favouring using two languages simultaneously in the same direction. I am not convinced that the coding with a character tacked on directly to the language tag is an acceptable coding, but want to test the reaction on this compromise proposal. --------------------------------------------------------------------------------------------------- The existing text is clearly not fine. It has a contradiction. In 6 it says: " The attribute value should be a language tag perRFC 5646 [RFC5646 ]" In 6.2 it says: " The attribute value should be a language tag perRFC 5646 [RFC5646 ]" But also "In an offer, each language tag value MAY have an asterisk appended as the last character (after the registry value)." And in 6.3: "The mechanism for indicating this preference is that, in an offer, if the last character of any of the 'humintlang-recv' or 'humintlang- send' values is an asterisk, this indicates a request to not fail the call." This indicates that the attribute value is both just a language tag and a language tag with a possibly attached *. That is not logical. The syntax description needs to be clearer. With the current coding it needs to indicate that the attribute value is composed of a language tag combined with an optional call disposition indication character. -------------------- /Gunnar ---------------------------------------- > >> On Aug 9, 2016, at 2:50 AM, slim issue tracker wrote: >> >> #7: The notation for Advisory vs Required is not logical and needs revision >> >> >> Comment (by gunnar.hellstrom@omnitor.se): >> >> Modify the text in change 1 to: >> >> The mechanism for indicating this preference is a session level attribute >> "humintlang-disposition", with "reject", "improve" and "connect" as >> possible values and "connect" as default. >> >> Example: >> a=humintlang-disposition: reject >> >> The called party MAY ignore the "reject" value, e.g., for the emergency >> services use case, a PSAP will likely not fail the call. >> >> -- >> -------------------------------------+------------------------------------- >> Reporter: | Owner: draft-ietf-slim- >> gunnar.hellstrom@omnitor.se | negotiating-human-language@ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: negotiating-human- | Version: >> language | Resolution: >> Severity: In WG Last Call | >> Keywords: reject | >> -------------------------------------+------------------------------------- >> >> Ticket URL: >> slim >> >> _______________________________________________ >> 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 --------------684F9DD1193203BE96EAB5C6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2016-08-09 kl. 15:01, skrev Brian Rosen:
I am not in favor of this change.  I think the existing text is fine.

Brian
The described function for advisory vs required in the draft is a session level function. That makes the coding very unusual when it is said that it can be attached to any media level language indication. I do not think that that kind of logic behind the coding is acceptable in an IETF document.

If you are really eager to keep the current syntax, we would need to add some media level semantics to the "don't reject" parameter. That is to give a specific meaning of which media, language and direction the parameter is tacked on to.

A possible coding would be to let the tacked on character indicate that the language it is tacked on to is the most favoured language.  There are two possible characters indicating two proposed dispositions in case of no match in the whole sdp.

"*" marks a most favoured language and that the call should be connected even if no language match was found in the whole sdp.
"+" marks a most favoured language and that the call should be rejected if no language match was found in the whole sdp.
It is most common to only have one most favoured language per direction, but it is allowed to use the indication for two languages in different modalities for the same direction if the user is favouring using two languages simultaneously in the same direction.

I am not convinced that the coding with a character tacked on directly to the language tag is an acceptable coding, but want to test the reaction on this compromise proposal.

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

The existing text is clearly not fine. It has a contradiction.
In 6 it says:  "
The attribute value should be a language tag per RFC 5646 [RFC5646]"
In 6.2 it says:
"
The attribute value should be a language tag per RFC 5646 [RFC5646]"

But also 
 "In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value)."

And in 6.3: 
"The mechanism for indicating this preference is that, in an offer, if
   the last character of any of the 'humintlang-recv' or 'humintlang-
   send' values is an asterisk, this indicates a request to not fail the
   call."

This indicates that the attribute value is both just a language tag and a language tag with a possibly attached *. That is not logical.

The syntax description needs to be clearer. With the current coding it needs to indicate that the attribute value is composed of a language tag combined with an optional call disposition indication character.

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


/Gunnar


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


 




On Aug 9, 2016, at 2:50 AM, slim issue tracker <trac+slim@tools.ietf.org> wrote:

#7: The notation for Advisory vs Required is not logical and needs revision


Comment (by gunnar.hellstrom@omnitor.se):

Modify the text in change 1 to:

The mechanism for indicating this preference is a session level attribute
"humintlang-disposition", with "reject", "improve" and "connect" as
possible values and "connect" as default.

Example:
a=humintlang-disposition: reject

The called party MAY ignore the "reject" value, e.g., for the emergency
services use case, a PSAP will likely not fail the call.

-- 
-------------------------------------+-------------------------------------
Reporter:                           |       Owner:  draft-ietf-slim-
 gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
    Type:  defect                   |      Status:  new
Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
 language                           |  Resolution:
Severity:  In WG Last Call          |
Keywords:  reject                   |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:1>
slim <https://tools.ietf.org/slim/>

_______________________________________________
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

  


--------------684F9DD1193203BE96EAB5C6--


From nobody Tue Aug 16 14:31:23 2016
Return-Path: 
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 D2C8212D176; Tue, 16 Aug 2016 14:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 X5pSWr3VO4t6; Tue, 16 Aug 2016 14:31:20 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7A012D0F9; Tue, 16 Aug 2016 14:31:20 -0700 (PDT)
Received: from localhost ([::1]:53937 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZlxA-0004nl-Cw; Tue, 16 Aug 2016 14:31:20 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se
X-Trac-Project: slim
Date: Tue, 16 Aug 2016 21:31:20 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/14#comment:1
Message-ID: <071.322b20adfed62b64d3da249fd1683b1a@tools.ietf.org>
References: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org>
X-Trac-Ticket-ID: 14
In-Reply-To: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160816213120.7A7A012D0F9@ietfa.amsl.com>
Resent-Date: Tue, 16 Aug 2016 14:31:20 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #14 (negotiating-human-language): Expand acronyms
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:31:22 -0000

#14: Expand acronyms


Comment (by gunnar.hellstrom@omnitor.se):

 The same topic is dealt with in issue #4. Possible references are provided
 in the discussion about issue#4.
 References to SA1 and CR are not needed. There is a published 3GPP
 specification with the requirements.

 The other acronyms could be included if it is decided that the references
 are wanted. ( It is unusual for IETF to tell where IETF documents are
 used, and not needed for the specification of the mechanism)

-- 
-------------------------------------+-------------------------------------
 Reporter:  doug@ewellic.org         |       Owner:  draft-ietf-slim-
     Type:  enhancement              |  negotiating-human-language@ietf.org
 Priority:  minor                    |      Status:  new
Component:  negotiating-human-       |   Milestone:
  language                           |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Tue Aug 16 14:34:07 2016
Return-Path: 
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 6C48F12B024 for ; Tue, 16 Aug 2016 14:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 H2gVXsw0JGfh for ; Tue, 16 Aug 2016 14:34:02 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C07D12B044 for ; Tue, 16 Aug 2016 14:34:02 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id v123so84359290qkh.2 for ; Tue, 16 Aug 2016 14:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RiVM9kQZhuwt0QQ6ZRbZL1DHKX+adT1P0IycHq7DlMY=; b=VtyE2c5PkZxixW5jBiwcRL+oH9klC21voUvCP1EskZUgNxvIUPketgddt/GbLSc5cZ Rx/JQYg1LI0savyV+pqEyUjoZ5/JfX+N8OwOJRpIHekVLy1XGk/VJ1LvzXoEWptcXs8E BdYVsWpUPwhjpSZCAGzcDUvIK7ZBKxLaPZcGkTD9nHv2RZe4g1+Xklf26XKqunG3CrdA Bf4ZmCiMzKtBLRHzQPmh4Rkeuh20oCnzb2vmOtLIfKimR1cgpjRFdIp7tG08hc1DgCYr abxhi8KQyglgybrBd4igfdGMuOovrqXb07dHliWfb9rs9SFC3/Wh5X5DH9rgP69MISJW 8qig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RiVM9kQZhuwt0QQ6ZRbZL1DHKX+adT1P0IycHq7DlMY=; b=HTwmf4HhxKPb7q7X/akY7xnLmIFx4PQ5d62APQbFCqEFYa2fwcZqcCtZqf5MAbji0/ avKv1uf6YcOyfbvHdaYkuxQISpsk4hUtVm+2wahxygC1RW5nGG5MEc/URwEVk/gtuop7 qqpiw7LOABUcBKhUoHzdnL9z9cmGLnp5T0yCn0BIDv2dkQsxtejJviI5nxXFqBqL8PVa BQcdNdj3M4oZ/ZXvvGSYkGtvOvPQCroZi3HlIi5c9h+P564tiWeHDCV0T9Gr0QK9XTfN fcFsHE8GBuYiFm7y3eSlB7BT21jpFhyyHHPQ5KcmnkXgXPiuJuYtMXmGEQZrn7fi4RY9 gErg==
X-Gm-Message-State: AEkoouvDGPejC7o2I9o559v/0NVAtjDC6YeDT4I0bwFUMNGsELK3bkqZTO35GIUpOZIzYQ==
X-Received: by 10.55.148.193 with SMTP id w184mr32030217qkd.181.1471383241391;  Tue, 16 Aug 2016 14:34:01 -0700 (PDT)
Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id g29sm16109581qtg.12.2016.08.16.14.34.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 14:34:00 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_218B5AC6-9E6B-4A82-AA1E-BF343BD25B3D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: 
Date: Tue, 16 Aug 2016 17:33:57 -0400
Message-Id: <8AD201A5-B63A-4D73-8B51-DB20DF93D5A8@brianrosen.net>
References: <067.ec4a6a56225e88252d9e65568f00723e@tools.ietf.org> <082.6cbababa93e825f163e92644f6e9d826@tools.ietf.org>  
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: slim@ietf.org, slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:34:05 -0000

--Apple-Mail=_218B5AC6-9E6B-4A82-AA1E-BF343BD25B3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I really don=92t think there is any confusion whatsoever in the current =
language.

I could see adding =93with an optional asterisk appended=94 after "per =
RFC 5446=94, but I don=92t think it=92s necessary.

Brian

Brian
> On Aug 16, 2016, at 5:19 PM, Gunnar Hellstr=F6m =
 wrote:
>=20
> Den 2016-08-09 kl. 15:01, skrev Brian Rosen:
>> I am not in favor of this change.  I think the existing text is fine.
>>=20
>> Brian
> The described function for advisory vs required in the draft is a =
session level function. That makes the coding very unusual when it is =
said that it can be attached to any media level language indication. I =
do not think that that kind of logic behind the coding is acceptable in =
an IETF document.
>=20
> If you are really eager to keep the current syntax, we would need to =
add some media level semantics to the "don't reject" parameter. That is =
to give a specific meaning of which media, language and direction the =
parameter is tacked on to.
>=20
> A possible coding would be to let the tacked on character indicate =
that the language it is tacked on to is the most favoured language.  =
There are two possible characters indicating two proposed dispositions =
in case of no match in the whole sdp.=20
>=20
> "*" marks a most favoured language and that the call should be =
connected even if no language match was found in the whole sdp.
> "+" marks a most favoured language and that the call should be =
rejected if no language match was found in the whole sdp.
> It is most common to only have one most favoured language per =
direction, but it is allowed to use the indication for two languages in =
different modalities for the same direction if the user is favouring =
using two languages simultaneously in the same direction.
>=20
> I am not convinced that the coding with a character tacked on directly =
to the language tag is an acceptable coding, but want to test the =
reaction on this compromise proposal.
>=20
> =
--------------------------------------------------------------------------=
-------------------------
>=20
> The existing text is clearly not fine. It has a contradiction.
> In 6 it says:  "
> The attribute value should be a language tag per RFC 5646 =
 [RFC5646 =
]"
> In 6.2 it says:
> "
> The attribute value should be a language tag per RFC 5646 =
 [RFC5646 =
]"
>=20
> But also=20
>  "In an offer, each language tag value MAY have an asterisk appended =
as
>    the last character (after the registry value)."
>=20
> And in 6.3:=20
> "The mechanism for indicating this preference is that, in an offer, if
>    the last character of any of the 'humintlang-recv' or 'humintlang-
>    send' values is an asterisk, this indicates a request to not fail =
the
>    call."
>=20
> This indicates that the attribute value is both just a language tag =
and a language tag with a possibly attached *. That is not logical.
>=20
> The syntax description needs to be clearer. With the current coding it =
needs to indicate that the attribute value is composed of a language tag =
combined with an optional call disposition indication character.
>=20
> --------------------
>=20
>=20
> /Gunnar
>=20
>=20
>  =20
> ----------------------------------------
>=20
>=20
> =20
>=20
>=20
>>> On Aug 9, 2016, at 2:50 AM, slim issue tracker =
  wrote:
>>>=20
>>> #7: The notation for Advisory vs Required is not logical and needs =
revision
>>>=20
>>>=20
>>> Comment (by gunnar.hellstrom@omnitor.se =
):
>>>=20
>>> Modify the text in change 1 to:
>>>=20
>>> The mechanism for indicating this preference is a session level =
attribute
>>> "humintlang-disposition", with "reject", "improve" and "connect" as
>>> possible values and "connect" as default.
>>>=20
>>> Example:
>>> a=3Dhumintlang-disposition: reject
>>>=20
>>> The called party MAY ignore the "reject" value, e.g., for the =
emergency
>>> services use case, a PSAP will likely not fail the call.
>>>=20
>>> --=20
>>> =
-------------------------------------+------------------------------------=
-
>>> Reporter:                           |       Owner:  draft-ietf-slim-
>>>  gunnar.hellstrom@omnitor.se     =
    |  negotiating-human-language@ietf.org =

>>>     Type:  defect                   |      Status:  new
>>> Priority:  major                    |   Milestone:
>>> Component:  negotiating-human-       |     Version:
>>>  language                           |  Resolution:
>>> Severity:  In WG Last Call          |
>>> Keywords:  reject                   |
>>> =
-------------------------------------+------------------------------------=
-
>>>=20
>>> Ticket URL: =
 =

>>> slim  
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/slim =

>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288


--Apple-Mail=_218B5AC6-9E6B-4A82-AA1E-BF343BD25B3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I really don=92t think there is any confusion whatsoever in =
the current language.

I could see adding =93with an optional asterisk appended=94 =
after "per RFC 5446=94, but I don=92t think it=92s necessary.

Brian

Brian
On =
Aug 16, 2016, at 5:19 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-08-09 kl. =
15:01, skrev Brian Rosen:
I am not in =
favor of this change.  I think the existing text is fine.

Brian
The described function for advisory vs required =
in the draft is a session level function. That makes the coding very =
unusual when it is said that it can be attached to any media level =
language indication. I do not think that that kind of logic behind the =
coding is acceptable in an IETF document.

If you are really eager to keep the current syntax, we would =
need to add some media level semantics to the "don't reject" parameter. =
That is to give a specific meaning of which media, language and =
direction the parameter is tacked on to.

A=
 possible coding would be to let the tacked on character indicate that =
the language it is tacked on to is the most favoured language.  =
There are two possible characters indicating two proposed dispositions =
in case of no match in the whole sdp. 

"*" marks a most favoured language and that the =
call should be connected even if no language match was found in the =
whole sdp.
"+" marks a most favoured language and that the =
call should be rejected if no language match was found in the whole =
sdp.
It is most common to only have one most favoured =
language per direction, but it is allowed to use the indication for two =
languages in different modalities for the same direction if the user is =
favouring using two languages simultaneously in the same =
direction.

I am not convinced =
that the coding with a character tacked on directly to the language tag =
is an acceptable coding, but want to test the reaction on this =
compromise proposal.

---------------------------------------------------------------=
------------------------------------

The existing text is clearly not fine. It has a =
contradiction.
In 6 it says:  =
"
The attribute value should be a language =
tag per RFC =
5646 [RFC5646]"
In 6.2 it says:
"
The attribute value should be a language tag per RFC 5646 [RFC5646]"

But also=20
 "In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value)."

And in 6.3:=20
"The mechanism for indicating this preference is that, in an offer, if
   the last character of any of the 'humintlang-recv' or 'humintlang-
   send' values is an asterisk, this indicates a request to not fail the
   call."

This indicates that the attribute value is both just a language tag and =
a language tag with a possibly attached *. That is not logical.

The syntax description needs to be clearer. With the current coding it =
needs to indicate that the attribute value is composed of a language tag =
combined with an optional call disposition indication character.

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



/Gunnar


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


 


On Aug 9, 2016, at 2:50 AM, slim issue tracker <trac+slim@tools.ietf.org><=
/a> wrote:

#7: The notation for Advisory vs Required is not logical and needs =
revision


Comment (by gunnar.hellstrom@omnitor.se):

Modify the text in change 1 to:

The mechanism for indicating this preference is a session level =
attribute
"humintlang-disposition", with "reject", "improve" and "connect" as
possible values and "connect" as default.

Example:
a=3Dhumintlang-disposition: reject

The called party MAY ignore the "reject" value, e.g., for the emergency
services use case, a PSAP will likely not fail the call.

--=20
=
-------------------------------------+------------------------------------=
-
Reporter:                           |       Owner:  draft-ietf-slim-
 gunnar.hellstrom@omnitor.se        |  negotiating-human-lang=
uage@ietf.org
    Type:  defect                   |      Status:  new
Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
 language                           |  Resolution:
Severity:  In WG Last Call          |
Keywords:  reject                   |
=
-------------------------------------+------------------------------------=
-

Ticket URL: <h=
ttps://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:1>
slim <https://tools.ietf.org/slim/>=


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m=
ailman/listinfo/slim


--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

=

--Apple-Mail=_218B5AC6-9E6B-4A82-AA1E-BF343BD25B3D--


From nobody Tue Aug 16 14:36:35 2016
Return-Path: 
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 AE2FC12D7CF; Tue, 16 Aug 2016 14:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 ySx8ygMl_pi0; Tue, 16 Aug 2016 14:36:31 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7B412D74B; Tue, 16 Aug 2016 14:36:31 -0700 (PDT)
Received: from localhost ([::1]:53992 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZm26-0003UP-GU; Tue, 16 Aug 2016 14:36:26 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, gunnar.hellstrom@omnitor.se
X-Trac-Project: slim
Date: Tue, 16 Aug 2016 21:36:26 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3
Message-ID: <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org>
X-Trac-Ticket-ID: 8
In-Reply-To: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com, gunnar.hellstrom@omnitor.se, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160816213631.6F7B412D74B@ietfa.amsl.com>
Resent-Date: Tue, 16 Aug 2016 14:36:31 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:36:33 -0000

#8: Introduce a section on most favoured modality


Comment (by gunnar.hellstrom@omnitor.se):

 This is not anymore a fully specified preference level between languages
 in different modalities. In this version it is just a single indication of
 the most favoured modality ( and by that the most favoured language).

 It is such a small addition, and so urgently needed to make the draft
 useful, that it should be allowed to be included.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
  language                           |  Resolution:  wontfix
 Severity:  In WG Last Call          |
 Keywords:  modality                 |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Tue Aug 16 14:40:09 2016
Return-Path: 
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 B4C5E12D1DE; Tue, 16 Aug 2016 14:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 Lbq4qJQrWGCN; Tue, 16 Aug 2016 14:40:06 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FDE12B024; Tue, 16 Aug 2016 14:40:06 -0700 (PDT)
Received: from localhost ([::1]:54110 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZm5b-0002PB-CZ; Tue, 16 Aug 2016 14:40:03 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com
X-Trac-Project: slim
Date: Tue, 16 Aug 2016 21:40:03 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:7
Message-ID: <082.91320352741e8dc75faf4f935d300495@tools.ietf.org>
References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org>
X-Trac-Ticket-ID: 6
In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160816214006.68FDE12B024@ietfa.amsl.com>
Resent-Date: Tue, 16 Aug 2016 14:40:06 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:40:08 -0000

#6: Collect information on modality in separate section for clarity


Comment (by gunnar.hellstrom@omnitor.se):

 The reason to close this one was misplaced.

 It is issue #10 that is a summary. This one is a unique effort to collect
 information about modality in one place because at the moment it is
 scattered and unclear and repeated.

 Please reopen.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
  language                           |  Resolution:  invalid
 Severity:  In WG Last Call          |
 Keywords:  modality                 |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Tue Aug 16 14:50:40 2016
Return-Path: 
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 CA31012D828 for ; Tue, 16 Aug 2016 14:50:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 2A8Y4k5I8VRZ for ; Tue, 16 Aug 2016 14:50:35 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4D312D822 for ; Tue, 16 Aug 2016 14:50:33 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id t7so3113837qkh.1 for ; Tue, 16 Aug 2016 14:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iFdmpZuHcrtwkq+DveJZZ+zPjCSW6HXI7iMBq2MWIsc=; b=ulVyNiSJUdzB5JU6awkO3xu4qS3G0zSZnErg+4y5XWhw1yJxWJit2j5dgr6bMJNBPB GQbKf9pA1ij3rwlkFWd/n/RA9p3iKPHRcRp2FbXb7DlrrTuhHmxrBGWJA+fElFxt35Ky Mi25qLqZiPiORu7SSw4veavU1whsaHHCeFZytqma30tlEwGqfyUNKh1R9VYiOgJNH9nt fsS7ivt2DfhgBX7Bj/mbSvJ3PgdiCVIKelwK8bFkzDMiSwI36ypmNaaJ9e1X4bF2QOND VH+nNHoBdUo2f+utre4tM/maphnyFdA/mwiyOmj1bfYcFkBuakJ17eXAp/mY1ecmvlbR uPEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iFdmpZuHcrtwkq+DveJZZ+zPjCSW6HXI7iMBq2MWIsc=; b=kOZ9iBormYJmH3yt+Q91eD+lQLQK2SV4i2HSXCvXVMJbxXr6x2p8wIqL259xMDtTDL V9zTwBoHnOhfdZMf5a+8q1NqyIEThGhrvdmQgM56XnyPG3ic0mrOrM7g+GjiMCgnSEJp 6uxxgALPHa0epZ3IaS5LaUXDlQ5yvoPyJZD7x4yHVtJPOY6IMj/p0jHbPg6SKjHUNBIg C1j5E32s0d0dxeKIlcEJ45uXjiaRgayrszAQdfBSCE6musOMY4l/JHSKMCTvBct1OKfJ XACsT1b02fZLJ9tcU7rlYxFdyOYLET9hU3dS18g2N1MvAFXI+PdDKW7vsjcFe0Hmj5lC eTwg==
X-Gm-Message-State: AEkooutN4KyXEs2dqrrvV6MKgELYmMlDEoLGhKjQxMguVKfCsYVfWU7SWpyKkZafbf7uzA==
X-Received: by 10.55.68.81 with SMTP id r78mr40119361qka.119.1471384232442; Tue, 16 Aug 2016 14:50:32 -0700 (PDT)
Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 95sm14864983qkx.15.2016.08.16.14.50.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 14:50:31 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org>
Date: Tue, 16 Aug 2016 17:50:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org>
To: slim issue tracker 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: slim@ietf.org, =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:50:39 -0000

I don=E2=80=99t think this is useful, and I think it=E2=80=99s beyond =
the consensus on what this document would contain.

If I send an offer of English audio and you can do it, then you will =
send an answer with English audio.  If you can=E2=80=99t do it, then =
your answer won=E2=80=99t include English audio.  Me telling you that =
English audio is most important doesn=E2=80=99t change your answer.  =
This is especially true with modality.  There is no way I can use advice =
of which modality is most important to you.  If you offer video, I =
answer with some video if I can do video.  If I can=E2=80=99t I won=E2=80=99=
t include a video answer.  Telling me you realty, really want video =
isn=E2=80=99t useful.

Please remember, we=E2=80=99re not designing user interfaces, we=E2=80=99r=
e designing protocols.

Brian


> On Aug 16, 2016, at 5:36 PM, slim issue tracker =
 wrote:
>=20
> #8: Introduce a section on most favoured modality
>=20
>=20
> Comment (by gunnar.hellstrom@omnitor.se):
>=20
> This is not anymore a fully specified preference level between =
languages
> in different modalities. In this version it is just a single =
indication of
> the most favoured modality ( and by that the most favoured language).
>=20
> It is such a small addition, and so urgently needed to make the draft
> useful, that it should be allowed to be included.
>=20
> --=20
> =
-------------------------------------+------------------------------------=
-
> Reporter:                           |       Owner:  draft-ietf-slim-
>  gunnar.hellstrom@omnitor.se        |  =
negotiating-human-language@ietf.org
>     Type:  enhancement              |      Status:  closed
> Priority:  major                    |   Milestone:
> Component:  negotiating-human-       |     Version:
>  language                           |  Resolution:  wontfix
> Severity:  In WG Last Call          |
> Keywords:  modality                 |
> =
-------------------------------------+------------------------------------=
-
>=20
> Ticket URL: =

> slim 
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Tue Aug 16 14:54:01 2016
Return-Path: 
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 25F2212D196 for ; Tue, 16 Aug 2016 14:54:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 GbZx6L8bFRgK for ; Tue, 16 Aug 2016 14:53:58 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A65312D0FD for ; Tue, 16 Aug 2016 14:53:58 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id z190so52946571qkc.0 for ; Tue, 16 Aug 2016 14:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vgiqd5GEEiUT5TMgDorWSnfvaud8bQBWeEd6MR6hXZY=; b=RP+zK2YJwM8MAqsk8FRhWBioD7Wx/sEPkWjj/zpwj2tW6CwJnKawmRXCOf5HG/3j3C PYRg1D1oosXXjvsg2Q6FNL6U+Pp4akoSH7b8C8rfRQcEI9uf59LEG3PbHxD3flKZe60A McxfHRk8F5baq3RUIA0ADC1ZsW2gvKmV6CPQuKqn+9rXED/CvtPO2cbFZ7KUeZK79eIf JYs2wj+2KYAA+u2h3gX1XxVvJaI5cX0Et4ULY2tbZ/GIvLli6mJLu3r0Fzt3vbh9NPBv 3s+d3ESHw8TcbXnL60vH9XTLz616WKropHpvGAXXdt+nOjrbGAMqUGKffy9x4SUAKHFT Gvew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vgiqd5GEEiUT5TMgDorWSnfvaud8bQBWeEd6MR6hXZY=; b=L1cq/ksvxafqVc80V1KVzfb77FxReKTSf4dJ5w+ovRbl3wSLgCllZVIf0rssUh61u+ FBCAc4DUf5SnwUutLtJ1yMK0CAVB6Awz9OrTuOUoWMatzGQlGhltBGvc6VqE1Zdv0F1+ 2qBUd4uL572WROy1gAYXhjeiiMEd8o0IVpDAFKGoNhwDVB6994O5zPKWqvovJ8aO2UCO 6WtKt69D6OLJ1R05r8bBLmcA4hmF3HTYbcLHUd4Blp493+OJGpcAjCM4Gr4uIalDKlzU bZqxJbB/5y10WTAzzr6e00NKyKVBrkPSnUJYow4YDwsD/bz591JZJcluortkTWCa5LVJ c9FA==
X-Gm-Message-State: AEkoousbwB3CyO0trZT4+TVpeGldf+EXGgFdic3OHWmPGwS6bLRUAQR57YceiEqYj6arEw==
X-Received: by 10.55.128.66 with SMTP id b63mr25507954qkd.69.1471384437155; Tue, 16 Aug 2016 14:53:57 -0700 (PDT)
Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r187sm13075880qkc.49.2016.08.16.14.53.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 14:53:56 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <082.91320352741e8dc75faf4f935d300495@tools.ietf.org>
Date: Tue, 16 Aug 2016 17:53:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> <082.91320352741e8dc75faf4f935d300495@tools.ietf.org>
To: slim issue tracker 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: bernard_aboba@hotmail.com, gunnar.hellstrom@omnitor.se, nrooney@gsma.com, draft-ietf-slim-negotiating-human-language@ietf.org, slim@ietf.org
Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:54:00 -0000

I think it should remain closed.  I don=E2=80=99t think this =
reorganization would be particularly helpful if we don=E2=80=99t =
implement all you modality extensions (per chair direction).

I think it would be a really bad idea to try to label applications by =
modality.  Just allow our tags on the m=3Dapplication SDP.  That=E2=80=99s=
 all we need.

Brian

> On Aug 16, 2016, at 5:40 PM, slim issue tracker =
 wrote:
>=20
> #6: Collect information on modality in separate section for clarity
>=20
>=20
> Comment (by gunnar.hellstrom@omnitor.se):
>=20
> The reason to close this one was misplaced.
>=20
> It is issue #10 that is a summary. This one is a unique effort to =
collect
> information about modality in one place because at the moment it is
> scattered and unclear and repeated.
>=20
> Please reopen.
>=20
> --=20
> =
-------------------------------------+------------------------------------=
-
> Reporter:                           |       Owner:  draft-ietf-slim-
>  gunnar.hellstrom@omnitor.se        |  =
negotiating-human-language@ietf.org
>     Type:  enhancement              |      Status:  closed
> Priority:  major                    |   Milestone:
> Component:  negotiating-human-       |     Version:
>  language                           |  Resolution:  invalid
> Severity:  In WG Last Call          |
> Keywords:  modality                 |
> =
-------------------------------------+------------------------------------=
-
>=20
> Ticket URL: =

> slim 
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Tue Aug 16 23:56:53 2016
Return-Path: 
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 03FC912B019; Tue, 16 Aug 2016 23:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 6Qrnjbb8E46R; Tue, 16 Aug 2016 23:56:50 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5A612B008; Tue, 16 Aug 2016 23:56:50 -0700 (PDT)
Received: from localhost ([::1]:36668 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZumL-0007M6-2H; Tue, 16 Aug 2016 23:56:45 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 06:56:45 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:8
Message-ID: <082.ee88e7cfaa9872b9064aba3fa68cdcb9@tools.ietf.org>
References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org>
X-Trac-Ticket-ID: 6
In-Reply-To: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, bernard_aboba@hotmail.com, nrooney@gsma.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160817065650.5B5A612B008@ietfa.amsl.com>
Resent-Date: Tue, 16 Aug 2016 23:56:50 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 06:56:52 -0000

#6: Collect information on modality in separate section for clarity


Comment (by gunnar.hellstrom@omnitor.se):

 If the new section is not accepted, we need to make at least three changes
 in the draft corresponding to change proposal 1, 2, and 3 above.

 1. Clearly specify that the humintlang attributes are allowed in the sdp
 specification of the application/webrtc-datachannel t140 subchannel and
 that humintlang attributes in that subchannel specification shall be
 understood as indication of written modality.
 The humintlang attributes will for that case be placed in sdp "a=dcsa:"
 attributes for that subchannel. That will also need to be stated in the
 formal rfc4566bis -formatted specification of the humintlang attributes.
 Since we know this usage for the written modality, the usage level dcsa
 must also be registered by IANA for the humintlang attributes, ( see 8.3
 in draft-ietf-mmusic-data-channel-sdpneg )


 Text proposal for 6.2 if not any new 6.x is created:

 "The t140 subchannel of a media stream specified by MIME type/subtype
 "application/webrtc-datachannel" is intended to be used for written
 modality. Capability to use this subchannel for human language
 communication shall be specified by placing the corresponding humintlang-
 send and humintlang-recv attributes in a=dcsa: attributes in the sdp
 specification of the subchannel.



 2. Modify the following paragraph in 6.2:
 " Note that while signed language tags are used with a video stream to
 indicate sign language, a spoken language tag for a video stream in
 parallel with an audio stream with the same spoken language tag
 indicates a request for a supplemental video stream to see the
 speaker."

 to
 " While signed language tags are used with a video stream to
 indicate sign language, a spoken/written language tag for a video stream
 indicates a view of a speaking person."

 Motivations for this change: a) The leading words "Note that" may be
 understood as start of less important informational information. b)It is
 not only in requests that this notation can be used, therefore the words
 "a request" are deleted. c) The requirement to have the same language in
 the audio stream is a complication that the users can take care of without
 the need to complicate the mechanism, therefore that requirement is
 deleted.

 However, there is another possible use of spoken/written language tags for
 video media. That is for text captions overlaid in the video stream. That
 is often used for stored and replayed media, but less often for
 conversational use. Are we sure we want to ignore that way of transmitting
 text? If not, a "written" modality parameter is needed for this case.

 3. Section 6.4 Silly states has this paragraph:

 "A spoken language tag for a video stream in conjunction with an audio
 stream with the same language might indicate a request for
 supplemental video to see the speaker."

 This is the same information as discussed under 2 above, but placed under
 the header "Silly states". It is not a silly state and it is fully
 described in 6.2, so I suggest to delete it.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
  language                           |  Resolution:  invalid
 Severity:  In WG Last Call          |
 Keywords:  modality                 |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 00:17:39 2016
Return-Path: 
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 7A62B127077 for ; Wed, 17 Aug 2016 00:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 AvFpR4n4qeXa for ; Wed, 17 Aug 2016 00:17:34 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 7E7FB12B057 for ; Wed, 17 Aug 2016 00:17:33 -0700 (PDT)
X-Halon-ID: a805a207-644a-11e6-88cf-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 17 Aug 2016 09:17:29 +0200 (CEST)
To: Brian Rosen , slim issue tracker 
References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> <082.91320352741e8dc75faf4f935d300495@tools.ietf.org> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 17 Aug 2016 09:17:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: bernard_aboba@hotmail.com, slim@ietf.org, nrooney@gsma.com, draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 07:17:36 -0000

Den 2016-08-16 kl. 23:53, skrev Brian Rosen:
> I think it should remain closed.  I don’t think this reorganization would be particularly helpful if we don’t implement all you modality extensions (per chair direction).
If the new section is not accepted, we need to make at least three 
changes in the draft corresponding to change proposal 1, 2, and 3 in 
issue #6.
I just posted proposals for these changes as comments to #6. I hope they 
are considered even if the state of the issue is currently closed. I 
still want it to be opened again.

The intention of my change proposals and introduction of the modality 
section is to bring clarity about use of modality. The current draft 
(-04) has some weaknesses in that area. It has nothing to do with the 
need to also put priority on modalities that is dealt with in issue #8.




>
> I think it would be a really bad idea to try to label applications by modality.  Just allow our tags on the m=application SDP.  That’s all we need.
So you mean that it is sufficient to register by IANA that 
humintlang-send and huminlang-recv are allowed in general in a=dcsa:  
attributes for placement in WebRTC subprotocols and the modality should 
be clear from what subprotocol it is used with.   Or the modality may 
need to be specified in the subprotocol spec?
The only one I know currently that we have this need for is the t140 
subprotocol. But others may appear. I thought the modality parameter in 
the attribute value was useful for indication of what modality is meant 
in either ambigous cases as video, and in less known cases as some 
m=application cases.


There is another modality that we have not discussed at all. That is the 
"text message" modality. It is not really interactive, but very often 
used together with interactive media in a kind of slow 
pseudo-conversational mode. One implmentation is MSRP that is specified 
by the m=message media. Is there any interest to extend our 
specification to handle that modality as well?

/Gunnar





>
> Brian
>
>> On Aug 16, 2016, at 5:40 PM, slim issue tracker  wrote:
>>
>> #6: Collect information on modality in separate section for clarity
>>
>>
>> Comment (by gunnar.hellstrom@omnitor.se):
>>
>> The reason to close this one was misplaced.
>>
>> It is issue #10 that is a summary. This one is a unique effort to collect
>> information about modality in one place because at the moment it is
>> scattered and unclear and repeated.
>>
>> Please reopen.
>>
>> -- 
>> -------------------------------------+-------------------------------------
>> Reporter:                           |       Owner:  draft-ietf-slim-
>>   gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
>>      Type:  enhancement              |      Status:  closed
>> Priority:  major                    |   Milestone:
>> Component:  negotiating-human-       |     Version:
>>   language                           |  Resolution:  invalid
>> Severity:  In WG Last Call          |
>> Keywords:  modality                 |
>> -------------------------------------+-------------------------------------
>>
>> Ticket URL: 
>> slim 
>>
>> _______________________________________________
>> 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


From nobody Wed Aug 17 03:23:43 2016
Return-Path: 
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 7C96A12B036 for ; Wed, 17 Aug 2016 03:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Xk4gxgjdkcxf for ; Wed, 17 Aug 2016 03:23:39 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7EE12D60F for ; Wed, 17 Aug 2016 03:23:38 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id 52so47072801qtq.3 for ; Wed, 17 Aug 2016 03:23:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QgmZGhf+v83jdzdqvs8/YngTjXpnYe2LdGdoU0afYWg=; b=IfFuH8ya7vp+HY/Y+3lC5gb/iqV66wa4mt6UWajd2V5nLM9mvP0uTyvvuGpXqrsBUU TjrYwfBudTxrM9Cj/FATERkHEucJ/ftTogi9L1ePaMgLDhlVIrI5aLKno/EAD/OA5NmF EsW7wBSHJ+JIZH4AtjU5YA917zkJFu6nU/+Bj27E/IDv1MUCY3F8MIN+oWYg2Lc7AYEi nXLh1zIbUNEVUGjKhc14iuto0olhxpfABHGn0UZ/jjlqm19ZTF0kbDpsUzv9JGtJXIVC VkCqTsDnjGP2/DEq98Iv45SuxiB71gPw5xsloHBu6jVCC8uHf0asYu6HGr5O6qPyKXin 7gKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QgmZGhf+v83jdzdqvs8/YngTjXpnYe2LdGdoU0afYWg=; b=Hbn1bKtPSlcCKud2uveqeskM0vOTsEkzKmX6SF9UWp6sTY4k++rSNLTYdaNXwjBVhh xXcwoBjoktY/Y3kqRmkT8SOV/kVGZEooJ40A0LLAHtK8cRajqMyl+NaCaWc72XXuUf4+ n+8+NdAC1SqR5Zp9FQ2n9qtxcsrMGrnglKjpJcfTNvtf9NMcO1ST/tOcUEHrgsqhBaTb 8o87G2EqmPrrJzqNEmzd9nX+8Ymd2UYKOKevhLX+V2KeeQ/wz6i5SqW5o90TIWheWYts 4h2j6XQm1tP0b3dPjtiHzfp9f1JdJ3SaFQlR/IP5AqzgkW1EocFXgWh40ANwid9nPHJV n/Zw==
X-Gm-Message-State: AEkoouv1mXHyVrgCUa1ePK/dSvOPv37WkHg6B/g1ffAf6If104EVJzaAiCwrDbCfhFl1/PppFqCyFUCirorrvA==
X-Received: by 10.237.33.111 with SMTP id 102mr44055556qtc.56.1471429417681; Wed, 17 Aug 2016 03:23:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.126.132 with HTTP; Wed, 17 Aug 2016 03:23:37 -0700 (PDT)
In-Reply-To: <1471344947.2545363.696694081.777D8CAE@webmail.messagingengine.com>
References: <56128392-5138-487C-9D99-151BC4C13D34@gsma.com> <50CFEBF2-EF1A-4720-9781-BE4FC34BAD7F@gsma.com> <1471344947.2545363.696694081.777D8CAE@webmail.messagingengine.com>
From: Nik Tomkinson 
Date: Wed, 17 Aug 2016 11:23:37 +0100
Message-ID: 
To: Alexey Melnikov 
Content-Type: multipart/alternative; boundary=94eb2c0c7d22c0c713053a41dbfa
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Early AD review of draft-ietf-slim-multilangcontent-04.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 10:23:42 -0000

--94eb2c0c7d22c0c713053a41dbfa
Content-Type: text/plain; charset=UTF-8

Thanks Alexey, I'll raise these as tickets and deal with them.

Nik.

On 16 August 2016 at 11:55, Alexey Melnikov  wrote:

> Hi,
>
> Hopefully this will help the discussion:
>
> In Section 3.2, message/global needs a reference (RFC 6532).
>
> In Section 4, 2nd para: you are restating a requirement from MIME. Don't
> use RFC 2119 keywords here.
>
> In Section 8 (all examples in subsections): From/To header fields must
> include email addresses in order to be syntactically correct.
>
> In Section 11: you need to use the official Media Type registration
> template from RFC 6838.
>
>
> On Mon, Aug 15, 2016, at 06:12 PM, Natasha Rooney wrote:
>
> Hi all,
>
> The chairs have reviewed the tickets we currently have and have asked the
> author to make edits where necessary. All the tickets we had were for the
> draft-ietf-slim-negotiating-human-language-04 draft. This means we likely
> have not had the required number of reviewers for the draft-ietf-slim-multilangcontent-04[2]
> draft. Therefore, here are the actions and next steps.
>
>
>    - *ACTION:* Randall, please take a look at the comments on the tickets
>    and make changes where necessary.
>    - *ACTION: All*, please review the draft-ietf-slim-multilangcontent-04[2]
>    draft, and send tickets if changes are needed
>    - Please also let us know you have read it, as then we know how many
>       reviewers there have been.
>       - *NEXT STEP: *After changes have been made, Bernard will start
>    pushing the document through the RFC process (requesting AD reviews etc.)
>
>
> If there are any questions please let us know! Many thanks!
>
> Natasha
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-slim-
> negotiating-human-language/
> [2] https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
>
> Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com |
> +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org
>
>
> On 22 Jul 2016, at 11:39, Natasha Rooney  wrote:
>
> Hi all,
>
> Thanks for the meeting this week. We are pleased to announce that both
> drafts below have entered into Working Group Last Call. We will aim to exit
> WGLC on 12th August, which gives us three week from today.
>
> draft-ietf-slim-multilangcontent-01
> Multiple Language Content Type
>
> draft-ietf-slim-negotiating-human-language-01
> Negotiating Human Language in Real-Time Communications
>
> *Issues: *if you have issues please submit these to the IETF Issue
> Tracker at [1]. Please feel free to discuss items on the list also.
>
> Thanks everyone!
>
> Natasha
>
> [1] https://tools.ietf.org/wg/slim/trac/newticket
>
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA |
> nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype:
> nrooney@gsm.org
>
>
> This email and its attachments are intended for the above named only and
> may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>
> This email and its attachments are intended for the above named only and
> may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
> *_______________________________________________*
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>


-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:


https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/


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

--94eb2c0c7d22c0c713053a41dbfa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Alexey, I'll raise these as tickets and deal wi=
th them.

Nik.

=

On 16 August 2016 at 11:55, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:






Hi,
Hopefully this will help the discussion:





In Section 3.2, message/global needs a reference (RFC 6532).






In Section 4, 2nd para: you are restating a requirement from MIME. Don'=
t use RFC 2119 keywords here.






In Section 8 (all examples in subsections): From/To header fields must incl=
ude email addresses in order to be syntactically correct.






In Section 11: you need to use the official Media Type registration templat=
e from=C2=A0RFC 6838.








On Mon, Aug 15, 2016, at 06:12 PM, Natasha Rooney wrote:


Hi all,





The chairs have reviewed the tickets we currently have and have asked =
the author to make edits where necessary. All the tickets we had were for t=
he draft-ietf-slim-negotiating-human-language-04 draft. This means we =
likely have not had the required
 number of reviewers for the draft-ietf-slim-multilangcontent-04[2] dr=
aft. Therefore, here are the actions and next steps.







  • ACTION: Randall, please take a look at the comments on =
the tickets and make changes where necessary.
  • ACTION: <=
span style=3D"color:rgb(255,38,0)">All, please review the=C2=A0d=
raft-ietf-slim-multilangcontent-04[2] draft, and send tickets if chang=
es are needed 
    

    • Please also let us know you have read it, as then we know how many =
reviewers there have been.
  • NEXT STEP: After ch=
anges have been made, Bernard will start pushing the document through the R=
FC process (requesting AD reviews etc.)=C2=A0





If there =
are any questions please let us know! Many thanks!


 


 Natasha


 





 


 Natasha Rooney | Internet Engineering Director | GSMA |=C2=A0nrooney@gsma.com=C2=A0| =
+44 (0) 7730=C2=A0219 765 | @thisNatasha | Skype:=
=C2=A0nrooney@gsm.org<=
/a>


 




















Hi all, 





Thanks for the meeting this week. We are pleased to announce that=
 both drafts below have entered into Working Group Last Call. We will aim t=
o exit WGLC on 12th August, which gives us three week from today. 





draft-ietf-slim-multilangcontent-01=C2=A0


 Multiple Language Content Type


 


 draft-ietf-slim-negotiating-human-language-01=C2=A0


 Negotiating Human Language in Real-Time=C2=A0Communications







Issues: if you have issues please submit these to the IETF Issu=
e Tracker at [1]. Please feel free to discuss items on the list also.=C2=A0=






Thanks everyone!


<=
div style=3D"letter-spacing:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">


Natasha


 


 [1]=C2=A0https://tools.ietf.org/wg/slim/trac/newticket
<=
/div>

 


 Natasha Rooney | Technologist, Web=C2=A0and Internet, W3C & IETF =
| GSMA |=C2=A0nrooney=
@gsma.com=C2=A0| +44 (0) 7730=C2=A0219 765 | @=
thisNatasha | Skype:=C2=A0nrooney@gsm.org


 















This
 email and its attachments are intended for the above named only and may be=
 confidential. If they have come to you in error you must take no action ba=
sed on them, nor must you copy or show them to anyone; please reply to this=
 email or call +44 207 356 0600
 and highlight the error.


_______________________________________________


 SLIM mailing list











This
 email and its attachments are intended for the above named only and may be=
 confidential. If they have come to you in error you must take no action ba=
sed on them, nor must you copy or show them to anyone; please reply to this=
 email or call +44 207 356 0600
 and highlight the error.
_______________________________________________


SLIM mailing list










_______________________________________________

SLIM mailing list

SLIM@ietf.org

https://www.ietf.org/mailman/listinfo/slim





-- 
=

-----------------------------=
------------------------------------
Multiple Language Content Type Inte=
rnet Draft:
https://datatracke=
r.ietf.org/doc/draft-ietf-slim-multilangcontent/
---------------------------------------=
--------------------------




--94eb2c0c7d22c0c713053a41dbfa--


From nobody Wed Aug 17 03:44:07 2016
Return-Path: 
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 62DC612B03D; Wed, 17 Aug 2016 03:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 p9ffCe-Z_xTE; Wed, 17 Aug 2016 03:44:03 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424BA12B077; Wed, 17 Aug 2016 03:44:02 -0700 (PDT)
Received: from localhost ([::1]:40731 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZyKH-0000qd-RV; Wed, 17 Aug 2016 03:44:01 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 10:44:01 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/16
Message-ID: <067.17357bff46e93bc02517aa24fb7315c7@tools.ietf.org>
X-Trac-Ticket-ID: 16
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817104402.424BA12B077@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 03:44:02 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] [slim] #16 (multilangcontent): Reference message/global
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 10:44:05 -0000

#16: Reference message/global

 In Section 3.2, message/global needs a reference (RFC 6532).

 Originally highlighted by Alexey

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  multilangcontent         |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 03:46:26 2016
Return-Path: 
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 D93BD126FDC; Wed, 17 Aug 2016 03:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 mdPoo75VHnq0; Wed, 17 Aug 2016 03:46:24 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8852128B44; Wed, 17 Aug 2016 03:46:24 -0700 (PDT)
Received: from localhost ([::1]:40771 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZyMa-00014q-PP; Wed, 17 Aug 2016 03:46:24 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 10:46:24 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/17
Message-ID: <067.b7a881d4710a91cf786273b9b1c762ea@tools.ietf.org>
X-Trac-Ticket-ID: 17
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817104624.D8852128B44@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 03:46:24 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] [slim] #17 (multilangcontent): Remove RFC 2119 keyword
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 10:46:26 -0000

#17: Remove RFC 2119 keyword

 In Section 4, 2nd para: you are restating a requirement from MIME. Don't
 use RFC 2119 keywords here.

 Originally highlighted by Alexey.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  multilangcontent         |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 03:47:31 2016
Return-Path: 
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 E6995128B44; Wed, 17 Aug 2016 03:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 GTdTiYWP6s4f; Wed, 17 Aug 2016 03:47:29 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F069A126FDC; Wed, 17 Aug 2016 03:47:28 -0700 (PDT)
Received: from localhost ([::1]:40805 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZyNc-0001dn-SU; Wed, 17 Aug 2016 03:47:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 10:47:28 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/18
Message-ID: <067.bcd7dc3f784434c7cf7b620e40c89803@tools.ietf.org>
X-Trac-Ticket-ID: 18
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817104728.F069A126FDC@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 03:47:28 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] [slim] #18 (multilangcontent): Email addresses in examples
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 10:47:30 -0000

#18: Email addresses in examples

 In Section 8 (all examples in subsections): From/To header fields must
 include email addresses in order to be syntactically correct.

 Originally highlighted by Alexey.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  multilangcontent         |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 03:48:17 2016
Return-Path: 
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 94F1212B02F; Wed, 17 Aug 2016 03:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 rpJBgecf6any; Wed, 17 Aug 2016 03:48:14 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A93126FDC; Wed, 17 Aug 2016 03:48:14 -0700 (PDT)
Received: from localhost ([::1]:40820 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZyOM-0001jV-Ay; Wed, 17 Aug 2016 03:48:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 10:48:14 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/19
Message-ID: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-Trac-Ticket-ID: 19
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817104814.72A93126FDC@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 03:48:14 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] [slim] #19 (multilangcontent): Use Media Type registration template
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 10:48:15 -0000

#19: Use Media Type registration template

 In Section 11: you need to use the official Media Type registration
 template from RFC 6838.

 Originally highlighted by Alexey.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  multilangcontent         |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 03:55:08 2016
Return-Path: 
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 DB75112B03D; Wed, 17 Aug 2016 03:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 AFtB0MqYh5bK; Wed, 17 Aug 2016 03:55:05 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C2A12B014; Wed, 17 Aug 2016 03:55:05 -0700 (PDT)
Received: from localhost ([::1]:40994 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZyUy-0002OO-Pd; Wed, 17 Aug 2016 03:55:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 10:55:04 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/20
Message-ID: <067.f59ecbf0a7c40a473fcaa875edcbf471@tools.ietf.org>
X-Trac-Ticket-ID: 20
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817105505.54C2A12B014@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 03:55:05 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] [slim] #20 (multilangcontent): Update reference to I-D.gellens-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 10:55:07 -0000

#20: Update reference to I-D.gellens-slim-negotiating-human-language

 Reference to I-D.gellens-slim-negotiating-human-language should be draft-
 ietf-slim-negotiating-human-language.

 This will change again before publication as the RFC numbers are assigned
 but for now it should be corrected.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  multilangcontent         |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 04:46:37 2016
Return-Path: 
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 03C1A12D7DD; Wed, 17 Aug 2016 04:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 nRuAtqzNNTdf; Wed, 17 Aug 2016 04:46:34 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADA212D9A9; Wed, 17 Aug 2016 04:44:47 -0700 (PDT)
Received: from localhost ([::1]:41765 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZzH4-0006BJ-Ue; Wed, 17 Aug 2016 04:44:46 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 11:44:46 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/11#comment:1
Message-ID: <071.6a3778672a2fb349c6e59c5990f77f6d@tools.ietf.org>
References: <056.2b11befad03603f2a3c590e5d3b5ae48@tools.ietf.org>
X-Trac-Ticket-ID: 11
In-Reply-To: <056.2b11befad03603f2a3c590e5d3b5ae48@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817114447.6ADA212D9A9@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 04:44:47 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #11 (multilangcontent): Remove buzzword
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 11:46:36 -0000

#11: Remove buzzword


Comment (by rfc.nik.tomkinson@gmail.com):

 Thanks Doug. This has actually been secretly bugging me for some time
 also, but just not enough to do anything about it. I will replace it with
 'significantly' as suggested.

 Nik.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-slim-
  doug@ewellic.org       |  multilangcontent@ietf.org
     Type:  enhancement  |      Status:  new
 Priority:  minor        |   Milestone:
Component:               |     Version:
  multilangcontent       |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 05:04:30 2016
Return-Path: 
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 3B9F012D612; Wed, 17 Aug 2016 05:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 IRYhPzl-KqjS; Wed, 17 Aug 2016 05:04:28 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C9312D5CB; Wed, 17 Aug 2016 05:04:28 -0700 (PDT)
Received: from localhost ([::1]:43204 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZza4-0006go-K3; Wed, 17 Aug 2016 05:04:24 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, nrooney@gsma.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 12:04:24 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/11#comment:2
Message-ID: <071.3ce2f03c9074c9a80906f56d79454e0d@tools.ietf.org>
References: <056.2b11befad03603f2a3c590e5d3b5ae48@tools.ietf.org>
X-Trac-Ticket-ID: 11
In-Reply-To: <056.2b11befad03603f2a3c590e5d3b5ae48@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, nrooney@gsma.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817120428.26C9312D5CB@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 05:04:28 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #11 (multilangcontent): Remove buzzword
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 12:04:29 -0000

#11: Remove buzzword

Changes (by nrooney@gsma.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-slim-
  doug@ewellic.org       |  multilangcontent@ietf.org
     Type:  enhancement  |      Status:  closed
 Priority:  minor        |   Milestone:
Component:               |     Version:
  multilangcontent       |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 06:22:26 2016
Return-Path: 
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 CB50012D92F for ; Wed, 17 Aug 2016 06:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 y0IURNDNCzv6 for ; Wed, 17 Aug 2016 06:22:22 -0700 (PDT)
Received: from bin-vsp-out-04.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 8D5AC12D931 for ; Wed, 17 Aug 2016 06:22:21 -0700 (PDT)
X-Halon-ID: 9c912cb6-647d-11e6-a96c-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 17 Aug 2016 15:22:14 +0200 (CEST)
To: Brian Rosen , slim issue tracker 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 17 Aug 2016 15:22:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------7D90CEB15D905722E19DFD1F"
Archived-At: 
Cc: slim@ietf.org, Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 13:22:25 -0000

This is a multi-part message in MIME format.
--------------7D90CEB15D905722E19DFD1F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
> I don’t think this is useful, and I think it’s beyond the consensus on what this document would contain.
>
> If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that English audio is most important doesn’t change your answer.  This is especially true with modality.  There is no way I can use advice of which modality is most important to you.  If you offer video, I answer with some video if I can do video.  If I can’t I won’t include a video answer.  Telling me you realty, really want video isn’t useful.
In some limited examples that would lead to successful call start.
But consider a couple of other simple cases:
A. Two common spoken languages:
I send an offer of spoken English and French in audio in both 
directions, and you have configured your device that you also know 
English and French in both directions.
Then, the protocol selects spoken English and puts that in the answer. 
In order for the call to complete successfully you then need to know 
that English both ways was selected, so that you start talking English 
in your answer. It would be a failure of our intentions if you only got 
a connected indication and needed to start asking me what language I 
prefer.
We do not specify how the information is conveyed to you, but it is.
Even if you knew French and Italian, you would need to know that the 
common language is French.

B.  One spoken and one written language
I send an offer with spoken English in audio and written English in 
text. I call you, and you have also configured spoken English in audio 
and written English in text.
We both prefer to talk if we have a chance.
The negotiation succeeds and you get an indication that audio and text 
are the available media. If you do not get any preference indication, 
you do not know how to start the call. You may try English text fist and 
type "Hi, welcome, what can I do for you". I notice that you type, so I 
answer in text, because I do not know if you can talk English. We might 
continue the whole call in text, or take the effort to ask if we can 
change to talking.
Not until you get to know that we both can use spoken English and that 
it is the preferred match, you get a chance to respond in spoken English 
and the call starts well. The device can convey the negotiation result 
to you without us specifyinng how, but we need to describe that my 
preference for spoken modality is conveyed by the protocol.


Many other examples can easily be constructed where we both need the 
preference between modalities and that the user get to know the result 
of the negotiation, or at least the best matching languages.

>
> Please remember, we’re not designing user interfaces, we’re designing protocols.
Yes, we specify the protocol for conveying information about language 
and modality between the sides involved in the call.
In most cases some mechanism that we do not describe needs to take this 
information to the user so that the call can be completed successfully.
The other way - that the user is expected to configure the languages and 
modalities is briefly mentioned in the introduction by these words:

"Since this is a protocol mechanism, the user equipment (UE client)

    needs to know the user's preferred languages; a reasonable technique
    could include a configuration mechanism with a default of the language of the user interface."

I suggest that we also say that "The result of the negotiation is expected to be provided to the user in most applications of this mechanism,
but it is out of scope to specify how this is done."

That would not be specifying user interface but clarifying the main purpose.

The paragraph in the introduction continues:

    "In some cases, a UE could tie
    language and media preferences, such as a preference for a video
    stream using a signed language and/or a text or audio stream using a
    written/spoken language."

I take this sentence as a promise that later in the document we will read how such preference between languages in different modalities
is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that.

It can be sufficient to add indication of the most preferred modality to the protocol, because within the modalities we have the order of the attributes as the preference order.



Gunnar

>
> Brian
>
>
>> On Aug 16, 2016, at 5:36 PM, slim issue tracker  wrote:
>>
>> #8: Introduce a section on most favoured modality
>>
>>
>> Comment (by gunnar.hellstrom@omnitor.se):
>>
>> This is not anymore a fully specified preference level between languages
>> in different modalities. In this version it is just a single indication of
>> the most favoured modality ( and by that the most favoured language).
>>
>> It is such a small addition, and so urgently needed to make the draft
>> useful, that it should be allowed to be included.
>>
>> -- 
>> -------------------------------------+-------------------------------------
>> Reporter:                           |       Owner:  draft-ietf-slim-
>>   gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
>>      Type:  enhancement              |      Status:  closed
>> Priority:  major                    |   Milestone:
>> Component:  negotiating-human-       |     Version:
>>   language                           |  Resolution:  wontfix
>> Severity:  In WG Last Call          |
>> Keywords:  modality                 |
>> -------------------------------------+-------------------------------------
>>
>> Ticket URL: 
>> slim 
>>
>> _______________________________________________
>> 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


--------------7D90CEB15D905722E19DFD1F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2016-08-16 kl. 23:50, skrev Brian Rosen:

    

      
I don’t think this is useful, and I think it’s beyond the consensus on what this document would contain.

If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that English audio is most important doesn’t change your answer.  This is especially true with modality.  There is no way I can use advice of which modality is most important to you.  If you offer video, I answer with some video if I can do video.  If I can’t I won’t include a video answer.  Telling me you realty, really want video isn’t useful.

    

    In some limited examples that would lead to successful call start. 

    But consider a couple of other simple cases:

    A. Two common spoken languages:

    I send an offer of spoken English and French in audio in both
    directions, and you have configured your device that you also know
    English and French in both directions. 

    Then, the protocol selects spoken English and puts that in the
    answer. In order for the call to complete successfully you then need
    to know that English both ways was selected, so that you start
    talking English in your answer. It would be a failure of our
    intentions if you only got a connected indication and needed to
    start asking me what language I prefer. 

    We do not specify how the information is conveyed to you, but it
    is.  

    Even if you knew French and Italian, you would need to know that the
    common language is French.

    

    B.  One spoken and one written language

    I send an offer with spoken English in audio and written English in
    text. I call you, and you have also configured spoken English in
    audio and written English in text. 

    We both prefer to talk if we have a chance. 

    The negotiation succeeds and you get an indication that audio and
    text are the available media. If you do not get any preference
    indication, you do not know how to start the call. You may try
    English text fist and type "Hi, welcome, what can I do for you". I
    notice that you type, so I answer in text, because I do not know if
    you can talk English. We might continue the whole call in text, or
    take the effort to ask if we can change to talking. 

    Not until you get to know that we both can use spoken English and
    that it is the preferred match, you get a chance to respond in
    spoken English and the call starts well. The device can convey the
    negotiation result to you without us specifyinng how, but we need to
    describe that my preference for spoken modality is conveyed by the
    protocol.

    

      

    Many other examples can easily be constructed where we both need the
    preference between modalities and that the user get to know the
    result of the negotiation, or at least the best matching languages.

        

    

      

Please remember, we’re not designing user interfaces, we’re designing protocols.

    

    Yes, we specify the protocol for conveying information about
    language and modality between the sides involved in the call. 

    In most cases some mechanism that we do not describe needs to take
    this information to the user so that the call can be completed
    successfully. 

    The other way - that the user is expected to configure the languages
    and modalities is briefly mentioned in the introduction by these
    words:

    

    "Since this is a protocol mechanism, the user equipment (UE client)
    
   needs to know the user's preferred languages; a reasonable technique
   could include a configuration mechanism with a default of the language of the user interface."

I suggest that we also say that "The result of the negotiation is expected to be provided to the user in most applications of this mechanism, 
but it is out of scope to specify how this is done."

That would not be specifying user interface but clarifying the main purpose.

The paragraph in the introduction continues:

   "In some cases, a UE could tie
   language and media preferences, such as a preference for a video
   stream using a signed language and/or a text or audio stream using a
   written/spoken language."

I take this sentence as a promise that later in the document we will read how such preference between languages in different modalities 
is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that. 

It can be sufficient to add indication of the most preferred modality to the protocol, because within the modalities we have the order of the attributes as the preference order. 



Gunnar



    

      

Brian




      

        
On Aug 16, 2016, at 5:36 PM, slim issue tracker <trac+slim@tools.ietf.org> wrote:

#8: Introduce a section on most favoured modality


Comment (by gunnar.hellstrom@omnitor.se):

This is not anymore a fully specified preference level between languages
in different modalities. In this version it is just a single indication of
the most favoured modality ( and by that the most favoured language).

It is such a small addition, and so urgently needed to make the draft
useful, that it should be allowed to be included.

-- 
-------------------------------------+-------------------------------------
Reporter:                           |       Owner:  draft-ietf-slim-
 gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
    Type:  enhancement              |      Status:  closed
Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
 language                           |  Resolution:  wontfix
Severity:  In WG Last Call          |
Keywords:  modality                 |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
slim <https://tools.ietf.org/slim/>

_______________________________________________
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

  


--------------7D90CEB15D905722E19DFD1F--


From nobody Wed Aug 17 06:25:53 2016
Return-Path: 
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 BBB0212D929 for ; Wed, 17 Aug 2016 06:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 Hzw-3CXI8b45 for ; Wed, 17 Aug 2016 06:25:50 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFAB12D815 for ; Wed, 17 Aug 2016 06:25:49 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id 52so48912205qtq.3 for ; Wed, 17 Aug 2016 06:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VPJc8cWRoxyYyaL8GZsRBPwX2HukzbiEYVjfugRm1hg=; b=zWZxw3zG25GcVY54rMql/eUh8AV+hcEL722Sz7Ubvnml2nRpLfBHl/IE5E3mEaGYBe MBmIM1N7oC5l0swSiN6K7B7laOhJcZgKH2hpkUds8+FMcAEj+RYw6tzvD6BHyVMl4HmR eLLykm+0yTrspumnKa5hH/0omdIivnGnCl7r26BhfGVJpGeC6h2Y6KW50Z/76lVChZsq w2D0WyOKy5IK8cgI/xkM4w9JWAMFkJkvZyZoDfB8vMXEjLjMjrR0hOjBT6CtCWRffvM9 hN+5poqL9XoOH/MkqKdVAGZiDAjol2wCcWHY5LgYWz6l2nJePH2wUyo5RAiMD+8w9zqq fM6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VPJc8cWRoxyYyaL8GZsRBPwX2HukzbiEYVjfugRm1hg=; b=PzzA5dCAZ/LiGHdWOwtsDZRVVsOn+aUErNWlyzk/Q9opXtjtFXENBaInBIxZAJCHUJ s7fOnSUQ3aEMsmeeRdCI9Hv2J38YfHc8iTSkCpWkUcKANrYhRs/KlCoGyigDV0ko4pnP J569+VaPGy1IUCI+WJO7vRAPqn+N64f4NlSmtaGstEwWeGJxRHIM0kcWWVm3PcWIbEvS 5itqX/oDkMv7lsvDcnIBjX8+Zdg+EkN7eq1pZq7iFnWVG2Ks22OeeZYnDrfRHECcIx4q T5mBHllEilC59a1gla51TmMH9mYh2n4oNb0OkEHHTHGIaUpKpwNog/jyBNjWgInmyxv/ LxTw==
X-Gm-Message-State: AEkooutYCf26jlLI5n9Bpj9Ku7CV7iPY6CK7eb+HBM7dTD9CSibpgT5FCAoTe8UXxN77sQ==
X-Received: by 10.237.44.66 with SMTP id f60mr44735082qtd.11.1471440348866; Wed, 17 Aug 2016 06:25:48 -0700 (PDT)
Received: from [10.0.1.9] (dynamic-acs-24-154-119-181.zoominternet.net. [24.154.119.181]) by smtp.gmail.com with ESMTPSA id l1sm17765959qtd.49.2016.08.17.06.25.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 06:25:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_128081A2-A62D-4085-9DD3-0B25CD7D93FD"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: 
Date: Wed, 17 Aug 2016 09:25:46 -0400
Message-Id: <0B2D04FD-EF3A-4D6F-A9EA-D09EBA1C6AD3@brianrosen.net>
References: <067.f9de4a43a0d69095ed4e53c907866b0a@tools.ietf.org> <082.91320352741e8dc75faf4f935d300495@tools.ietf.org>  
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: bernard_aboba@hotmail.com, slim@ietf.org, slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org, nrooney@gsma.com
Subject: Re: [Slim] [slim] #6 (negotiating-human-language): Collect information on modality in separate section for clarity
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 13:25:53 -0000

--Apple-Mail=_128081A2-A62D-4085-9DD3-0B25CD7D93FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Aug 17, 2016, at 3:17 AM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
> Den 2016-08-16 kl. 23:53, skrev Brian Rosen:
>> I think it should remain closed.  I don=E2=80=99t think this =
reorganization would be particularly helpful if we don=E2=80=99t =
implement all you modality extensions (per chair direction).
> If the new section is not accepted, we need to make at least three =
changes in the draft corresponding to change proposal 1, 2, and 3 in =
issue #6.
> I just posted proposals for these changes as comments to #6. I hope =
they are considered even if the state of the issue is currently closed. =
I still want it to be opened again.
>=20
> The intention of my change proposals and introduction of the modality =
section is to bring clarity about use of modality. The current draft =
(-04) has some weaknesses in that area. It has nothing to do with the =
need to also put priority on modalities that is dealt with in issue #8.
>=20
>=20
>=20
>=20
>>=20
>> I think it would be a really bad idea to try to label applications by =
modality.  Just allow our tags on the m=3Dapplication SDP.  That=E2=80=99s=
 all we need.
> So you mean that it is sufficient to register by IANA that =
humintlang-send and huminlang-recv are allowed in general in a=3Ddcsa:  =
attributes for placement in WebRTC subprotocols and the modality should =
be clear from what subprotocol it is used with.   Or the modality may =
need to be specified in the subprotocol spec?
> The only one I know currently that we have this need for is the t140 =
subprotocol. But others may appear. I thought the modality parameter in =
the attribute value was useful for indication of what modality is meant =
in either ambigous cases as video, and in less known cases as some =
m=3Dapplication cases.
I=E2=80=99m not sure we need to specify the a=3D line the tags go on.  I =
think it=E2=80=99s just sufficient to say we can put a humintlang tag on =
an m=3Dapplication SDP section.  I think the modality will be clear in =
context.
>=20
>=20
> There is another modality that we have not discussed at all. That is =
the "text message" modality. It is not really interactive, but very =
often used together with interactive media in a kind of slow =
pseudo-conversational mode. One implmentation is MSRP that is specified =
by the m=3Dmessage media. Is there any interest to extend our =
specification to handle that modality as well?
Yeah, I=E2=80=99d like to do that.

>=20
> /Gunnar
>=20
>=20
>=20
>=20
>=20
>>=20
>> Brian
>>=20
>>> On Aug 16, 2016, at 5:40 PM, slim issue tracker =
 wrote:
>>>=20
>>> #6: Collect information on modality in separate section for clarity
>>>=20
>>>=20
>>> Comment (by gunnar.hellstrom@omnitor.se):
>>>=20
>>> The reason to close this one was misplaced.
>>>=20
>>> It is issue #10 that is a summary. This one is a unique effort to =
collect
>>> information about modality in one place because at the moment it is
>>> scattered and unclear and repeated.
>>>=20
>>> Please reopen.
>>>=20
>>> --=20
>>> =
-------------------------------------+------------------------------------=
-
>>> Reporter:                           |       Owner:  draft-ietf-slim-
>>>  gunnar.hellstrom@omnitor.se        |  =
negotiating-human-language@ietf.org
>>>     Type:  enhancement              |      Status:  closed
>>> Priority:  major                    |   Milestone:
>>> Component:  negotiating-human-       |     Version:
>>>  language                           |  Resolution:  invalid
>>> Severity:  In WG Last Call          |
>>> Keywords:  modality                 |
>>> =
-------------------------------------+------------------------------------=
-
>>>=20
>>> Ticket URL: =

>>> slim 
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288


--Apple-Mail=_128081A2-A62D-4085-9DD3-0B25CD7D93FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Aug 17, 2016, at 3:17 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-08-16 kl. 23:53, skrev Brian =
Rosen:
I think =
it should remain closed.  I don=E2=80=99t think this reorganization =
would be particularly helpful if we don=E2=80=99t implement all you =
modality extensions (per chair direction).
If the new section is not =
accepted, we need to make at least three changes in the draft =
corresponding to change proposal 1, 2, and 3 in issue #6.
I just posted =
proposals for these changes as comments to #6. I hope they are =
considered even if the state of the issue is currently closed. I still =
want it to be opened again.

The intention of my change proposals and =
introduction of the modality section is to bring clarity about use of =
modality. The current draft (-04) has some weaknesses in that area. It =
has nothing to do with the need to also put priority on modalities that =
is dealt with in issue #8.





I think it would be a really bad idea to try to label =
applications by modality.  Just allow our tags on the m=3Dapplication=
 SDP.  That=E2=80=99s all we need.
So you mean that it is sufficient to register by =
IANA that humintlang-send and huminlang-recv are allowed in general in =
a=3Ddcsa:  attributes for placement in WebRTC subprotocols and the =
modality should be clear from what subprotocol it is used with. =
  Or the modality may need to be specified in the subprotocol =
spec?
The only one I know currently that we have this =
need for is the t140 subprotocol. But others may appear. I thought the =
modality parameter in the attribute value was useful for indication of =
what modality is meant in either ambigous cases as video, and in less =
known cases as some m=3Dapplication cases.
I=E2=80=99m not sure we need to =
specify the a=3D line the tags go on.  I think it=E2=80=99s just =
sufficient to say we can put a humintlang tag on an m=3Dapplication SDP =
section.  I think the modality will be clear in =
context.


There is another =
modality that we have not discussed at all. That is the "text message" =
modality. It is not really interactive, but very often used together =
with interactive media in a kind of slow pseudo-conversational mode. One =
implmentation is MSRP that is specified by the m=3Dmessage media. Is =
there any interest to extend our specification to handle that modality =
as well?
Yeah, I=E2=80=99d like to do =
that.


/Gunnar






Brian

On Aug =
16, 2016, at 5:40 PM, slim issue tracker <trac+slim@tools.ietf.org> wrote:

#6: Collect information on modality in separate section for =
clarity


Comment (by gunnar.hellstrom@omnitor.se):

The reason to close this one was misplaced.

It is issue #10 that is a summary. This one is a unique =
effort to collect
information about modality in one place =
because at the moment it is
scattered and unclear and =
repeated.

Please reopen.

-- 
-------------------------------------+-------------------------=
------------
Reporter: =
            &n=
bsp;           &nbs=
p; |       Owner: =
 draft-ietf-slim-
 gunnar.hellstrom@omnitor.se =
       |  negotiating-human-language@ietf.org
    Type:  enhancement =
            &n=
bsp;|      Status:  closed
Priority:  major =
            &n=
bsp;      |   Milestone:
Component:  negotiating-human- =
      | =
    Version:
 language =
            &n=
bsp;           &nbs=
p; |  Resolution:  invalid
Severity: =
 In WG Last Call =
         |
Keywords:  modality =
            &n=
bsp;   |
-------------------------------------+-------------------------=
------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/6#comment:7=
>
slim <https://tools.ietf.org/slim/>

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar =
Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 =
288

=

--Apple-Mail=_128081A2-A62D-4085-9DD3-0B25CD7D93FD--


From nobody Wed Aug 17 06:42:10 2016
Return-Path: 
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 19E8F12D74D for ; Wed, 17 Aug 2016 06:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 Om0UGnZu8O-V for ; Wed, 17 Aug 2016 06:42:07 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C21512D818 for ; Wed, 17 Aug 2016 06:35:11 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id z190so68148663qkc.0 for ; Wed, 17 Aug 2016 06:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=34EtcF7ZPIJwT3eYaq9pZOmLro1yRW/bb+Sdeful2SE=; b=szO3H0nUeN0Hw5Z6CHPx8dZ9jYHhqa1z4taVmtBcCULgpNjP7yA8NsLSJeJhyezepx OUCvwCZyJq9ZyNuLZvbFtC/ePxSL4CCW7XwNkIpIo4krKctjMTzWnv1P165xeW9K/0NJ QwXdwmnd/uSCRKggSzh3IqHsrDu5Ac2ZfHNlYlPdsYIkQt3wHUyrfDXeLWXTWrbiZGP3 ALOMAXkqAQ2RMwywJPb538tup1hzmTYCyDPQJvh1NbDDlQ0llmObfIAr5ybRc+4AYd5d /xz8tmoYqOwvZwcHGIAJLzseq8RBvLyAPSkknLow4EFTiP632YotTlU7/OfSE+O4jYVA gsZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=34EtcF7ZPIJwT3eYaq9pZOmLro1yRW/bb+Sdeful2SE=; b=WB8xJToMkSuuBBmmE1UeXmajwx69v+TMKqz9k8TuO4tm2B/fOJcXFakVoF583N+apO EvrljAbP5cvVlWS+P6NHGNi8pGPaDonGLgBvfoiQu3AoN580tuVc3r47WhSIkbsjOUkV m4W1NGHjQzQFvSm7EyND5uwPVVcxjOhqb9yHYMrudXq8yUCVm9Wm01aVv0LResHhf4PF Wzp6c21RgdHSpwyxER7yRgIqU1fHZlPNSLQxSO708bzXKsCXbWip3lowVOhXIav4d17G gMy3acs3nD8TYYIFe2DzK5hZVTD0gw0qTl7lOXnSmrl/9juMJAO/9zJEp6ydl+yY7meu GyOA==
X-Gm-Message-State: AEkoouvFu7aERR6sqSFirSNcDdh7OdrUQCVJzxfKMM/AD8oinHdTH/cbrGizvPySyxrwdw==
X-Received: by 10.55.5.17 with SMTP id 17mr44169035qkf.280.1471440910175; Wed, 17 Aug 2016 06:35:10 -0700 (PDT)
Received: from [10.0.1.9] (dynamic-acs-24-154-119-181.zoominternet.net. [24.154.119.181]) by smtp.gmail.com with ESMTPSA id j188sm16605750qke.22.2016.08.17.06.35.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 06:35:09 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5362A75-0C23-471B-B933-7A13B584D0B2"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: 
Date: Wed, 17 Aug 2016 09:35:07 -0400
Message-Id: <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net> 
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Natasha Rooney , slim@ietf.org, slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 13:42:09 -0000

--Apple-Mail=_C5362A75-0C23-471B-B933-7A13B584D0B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>> I don=E2=80=99t think this is useful, and I think it=E2=80=99s beyond =
the consensus on what this document would contain.
>>=20
>> If I send an offer of English audio and you can do it, then you will =
send an answer with English audio.  If you can=E2=80=99t do it, then =
your answer won=E2=80=99t include English audio.  Me telling you that =
English audio is most important doesn=E2=80=99t change your answer.  =
This is especially true with modality.  There is no way I can use advice =
of which modality is most important to you.  If you offer video, I =
answer with some video if I can do video.  If I can=E2=80=99t I won=E2=80=99=
t include a video answer.  Telling me you realty, really want video =
isn=E2=80=99t useful.
> In some limited examples that would lead to successful call start.=20
> But consider a couple of other simple cases:
> A. Two common spoken languages:
> I send an offer of spoken English and French in audio in both =
directions, and you have configured your device that you also know =
English and French in both directions.=20
> Then, the protocol selects spoken English and puts that in the answer. =
In order for the call to complete successfully you then need to know =
that English both ways was selected, so that you start talking English =
in your answer. It would be a failure of our intentions if you only got =
a connected indication and needed to start asking me what language I =
prefer.=20
> We do not specify how the information is conveyed to you, but it is. =20=

The protocol answer was English.  Both ends know that.  User interface =
is out of scope.

> Even if you knew French and Italian, you would need to know that the =
common language is French.
>=20
> B.  One spoken and one written language
> I send an offer with spoken English in audio and written English in =
text. I call you, and you have also configured spoken English in audio =
and written English in text.=20
> We both prefer to talk if we have a chance.=20
> The negotiation succeeds and you get an indication that audio and text =
are the available media. If you do not get any preference indication, =
you do not know how to start the call. You may try English text fist and =
type "Hi, welcome, what can I do for you". I notice that you type, so I =
answer in text, because I do not know if you can talk English. We might =
continue the whole call in text, or take the effort to ask if we can =
change to talking.=20
> Not until you get to know that we both can use spoken English and that =
it is the preferred match, you get a chance to respond in spoken English =
and the call starts well. The device can convey the negotiation result =
to you without us specifyinng how, but we need to describe that my =
preference for spoken modality is conveyed by the protocol.
The protocol exchange informs BOTH ENDS that both voice and text is =
negotiated.  It=E2=80=99s perfectly fine for either end to start in =
either modality, and switch any time they want to.

>=20
>  =20
> Many other examples can easily be constructed where we both need the =
preference between modalities and that the user get to know the result =
of the negotiation, or at least the best matching languages.
>    =20
>> Please remember, we=E2=80=99re not designing user interfaces, we=E2=80=99=
re designing protocols.
> Yes, we specify the protocol for conveying information about language =
and modality between the sides involved in the call.=20
> In most cases some mechanism that we do not describe needs to take =
this information to the user so that the call can be completed =
successfully.=20
> The other way - that the user is expected to configure the languages =
and modalities is briefly mentioned in the introduction by these words:
>=20
> "Since this is a protocol mechanism, the user equipment (UE client)
>    needs to know the user's preferred languages; a reasonable =
technique
>    could include a configuration mechanism with a default of the =
language of the user interface.=E2=80=9D
That=E2=80=99s in scope, because it=E2=80=99s discussing configuration =
for the protocol exchange.
>=20
> I suggest that we also say that "The result of the negotiation is =
expected to be provided to the user in most applications of this =
mechanism,=20
> but it is out of scope to specify how this is done.=E2=80=9D
That=E2=80=99s out of scope, that=E2=80=99s strictly user interface

>=20
> That would not be specifying user interface but clarifying the main =
purpose.
>=20
> The paragraph in the introduction continues:
>=20
>    "In some cases, a UE could tie
>    language and media preferences, such as a preference for a video
>    stream using a signed language and/or a text or audio stream using =
a
>    written/spoken language."
>=20
> I take this sentence as a promise that later in the document we will =
read how such preference between languages in different modalities=20
> is coded and conveyed between the UEs. Our work is not complete and =
does not do its job until we have specified a mechanism for that.=20
We can edit this text to remove the inference.

>=20
> It can be sufficient to add indication of the most preferred modality =
to the protocol, because within the modalities we have the order of the =
attributes as the preference order.=20
>=20
>=20
>=20
> Gunnar
>=20
>> Brian
>>=20
>>=20
>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker =
  wrote:
>>>=20
>>> #8: Introduce a section on most favoured modality
>>>=20
>>>=20
>>> Comment (by gunnar.hellstrom@omnitor.se =
):
>>>=20
>>> This is not anymore a fully specified preference level between =
languages
>>> in different modalities. In this version it is just a single =
indication of
>>> the most favoured modality ( and by that the most favoured =
language).
>>>=20
>>> It is such a small addition, and so urgently needed to make the =
draft
>>> useful, that it should be allowed to be included.
>>>=20
>>> --=20
>>> =
-------------------------------------+------------------------------------=
-
>>> Reporter:                           |       Owner:  draft-ietf-slim-
>>>  gunnar.hellstrom@omnitor.se     =
    |  negotiating-human-language@ietf.org =

>>>     Type:  enhancement              |      Status:  closed
>>> Priority:  major                    |   Milestone:
>>> Component:  negotiating-human-       |     Version:
>>>  language                           |  Resolution:  wontfix
>>> Severity:  In WG Last Call          |
>>> Keywords:  modality                 |
>>> =
-------------------------------------+------------------------------------=
-
>>>=20
>>> Ticket URL: =
 =

>>> slim  
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/slim =

>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288


--Apple-Mail=_C5362A75-0C23-471B-B933-7A13B584D0B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-08-16 kl. =
23:50, skrev Brian Rosen:
I don=E2=80=99t =
think this is useful, and I think it=E2=80=99s beyond the consensus on =
what this document would contain.

If I send an offer of English audio and you can do it, then you will =
send an answer with English audio.  If you can=E2=80=99t do it, then =
your answer won=E2=80=99t include English audio.  Me telling you that =
English audio is most important doesn=E2=80=99t change your answer.  =
This is especially true with modality.  There is no way I can use advice =
of which modality is most important to you.  If you offer video, I =
answer with some video if I can do video.  If I can=E2=80=99t I won=E2=80=99=
t include a video answer.  Telling me you realty, really want video =
isn=E2=80=99t useful.
In some limited examples that would lead to =
successful call start. 
But consider a couple of other simple cases:
A. Two common spoken languages:
I send an offer of =
spoken English and French in audio in both directions, and you have =
configured your device that you also know English and French in both =
directions. 
Then, the protocol selects spoken English and puts that in =
the answer. In order for the call to complete successfully you then need =
to know that English both ways was selected, so that you start talking =
English in your answer. It would be a failure of our intentions if you =
only got a connected indication and needed to start asking me what =
language I prefer. 
We do not specify how the information is conveyed to you, but =
it is.  
The protocol answer was English. =
 Both ends know that.  User interface is out of =
scope.

Even if you knew French and Italian, you would need to know =
that the common language is French.

B.  One spoken and one written language
I=
 send an offer with spoken English in audio and written English in text. =
I call you, and you have also configured spoken English in audio and =
written English in text. 
We both prefer to talk if we have a chance. 
The negotiation succeeds and you get an indication that audio =
and text are the available media. If you do not get any preference =
indication, you do not know how to start the call. You may try English =
text fist and type "Hi, welcome, what can I do for you". I notice that =
you type, so I answer in text, because I do not know if you can talk =
English. We might continue the whole call in text, or take the effort to =
ask if we can change to talking. 
Not until you get to know that we both can use spoken English =
and that it is the preferred match, you get a chance to respond in =
spoken English and the call starts well. The device can convey the =
negotiation result to you without us specifyinng how, but we need to =
describe that my preference for spoken modality is conveyed by the =
protocol.
The protocol exchange =
informs BOTH ENDS that both voice and text is negotiated.  It=E2=80=99=
s perfectly fine for either end to start in either modality, and switch =
any time they want to.


  
Many other examples can easily be constructed where we both =
need the preference between modalities and that the user get to know the =
result of the negotiation, or at least the best matching =
languages.
    
Please =
remember, we=E2=80=99re not designing user interfaces, we=E2=80=99re =
designing protocols.
Yes, we specify the protocol for conveying =
information about language and modality between the sides involved in =
the call. 
In most cases some mechanism that we do not describe needs to =
take this information to the user so that the call can be completed =
successfully. The other way - that the user is expected to configure the =
languages and modalities is briefly mentioned in the introduction by =
these words:

"Since this is a =
protocol mechanism, the user equipment (UE client)
   needs to know the user's preferred languages; a reasonable =
technique
   could include a configuration mechanism with a default of the =
language of the user interface.=E2=80=9D
That=E2=80=
=99s in scope, because it=E2=80=99s discussing configuration for the =
protocol exchange.
I suggest that we also say that "The result of the negotiation is =
expected to be provided to the user in most applications of this =
mechanism,=20
but it is out of scope to specify how this is done.=E2=80=9D

That=E2=80=99s out of scope, that=E2=80=99s =
strictly user interface

That would not be specifying user interface but clarifying the main =
purpose.

The paragraph in the introduction continues:

   "In some cases, a UE could tie
   language and media preferences, such as a preference for a video
   stream using a signed language and/or a text or audio stream using a
   written/spoken language."

I take this sentence as a promise that later in the document we will =
read how such preference between languages in different modalities=20
is coded and conveyed between the UEs. Our work is not complete and does =
not do its job until we have specified a mechanism for that.=20

We can edit this text to remove the =
inference.

It can be sufficient to add indication of the most preferred modality to =
the protocol, because within the modalities we have the order of the =
attributes as the preference order.=20



Gunnar


Brian



On =
Aug 16, 2016, at 5:36 PM, slim issue tracker <trac+slim@tools.ietf.org><=
/a> wrote:

#8: Introduce a section on most favoured modality


Comment (by gunnar.hellstrom@omnitor.se):

This is not anymore a fully specified preference level between languages
in different modalities. In this version it is just a single indication =
of
the most favoured modality ( and by that the most favoured language).

It is such a small addition, and so urgently needed to make the draft
useful, that it should be allowed to be included.

--=20
=
-------------------------------------+------------------------------------=
-
Reporter:                           |       Owner:  draft-ietf-slim-
 gunnar.hellstrom@omnitor.se        |  negotiating-human-lang=
uage@ietf.org
    Type:  enhancement              |      Status:  closed
Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
 language                           |  Resolution:  wontfix
Severity:  In WG Last Call          |
Keywords:  modality                 |
=
-------------------------------------+------------------------------------=
-

Ticket URL: <h=
ttps://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
slim <https://tools.ietf.org/slim/>=


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m=
ailman/listinfo/slim


--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

=

--Apple-Mail=_C5362A75-0C23-471B-B933-7A13B584D0B2--


From nobody Wed Aug 17 06:42:42 2016
Return-Path: 
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 D476212D7F7; Wed, 17 Aug 2016 06:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 x4DnLvJWZRvk; Wed, 17 Aug 2016 06:42:39 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79DD12D94D; Wed, 17 Aug 2016 06:42:38 -0700 (PDT)
Received: from localhost ([::1]:50327 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba178-0000qK-L0; Wed, 17 Aug 2016 06:42:38 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 13:42:38 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/21
Message-ID: <067.033bb4c75a1be073bf1638fc7b12a580@tools.ietf.org>
X-Trac-Ticket-ID: 21
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160817134238.C79DD12D94D@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 06:42:38 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] [slim] #21 (negotiating-human-language): Add the text message modality to the realtime draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 13:42:41 -0000

#21: Add the text message modality to the realtime draft

 There is a modality that we have not discussed at all yet. That is the
 "text message" modality. It is not really interactive, but very often used
 together with interactive media in a kind of slow pseudo-conversational
 mode. One implementation is MSRP that is specified by the m=message media.
 There seems to be some interest to extend our specification to handle that
 modality as well.

 Then the text message modality needs to be described and how it is
 implicitly identified in sdp both in the main media m=message and in a
 subchannel of a data channel.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  negotiating-human-       |    Version:
  language                           |   Keywords:  message
 Severity:  In WG Last Call          |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 06:55:48 2016
Return-Path: 
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 EBA4C12D9F4 for ; Wed, 17 Aug 2016 06:55:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 QcUFDWsnEv85 for ; Wed, 17 Aug 2016 06:55:45 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5554712D9DB for ; Wed, 17 Aug 2016 06:55:28 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id w38so49336720qtb.0 for ; Wed, 17 Aug 2016 06:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWRGMfAvUTgdiF/l6G//po8ZlyfF4lwa5tJ+fK6Ad0c=; b=zeLdj55FyDzvt15VrMUGZDMSYmXubL8rgNnj/lwWKoO+znez8HorgdsvEWU3KnX3+B jgkmZRwreNEOENKOGirpbH+/U+QaZy2dJ4ry+nXCmKvO1fvBwBoOmZHMlaZI8QYGQRgQ 5N+QZBuXOMI3NU6EBblimBzdWtEOktI+6Wbos799/qBy1qO8N3vxZ12YnZzTdRmydWI7 boo2ffstOteKob2+GUwmDPfXsy0kwBB9SskPpqwfXuFcJmyRs1ujY3lbJNLiG/UsWncm tW/66VtwKIw1lXO6CYAz+Bx8V/CWLuAtqNrH3VqBm3ZUaKhCkwmsqSUmel2xChrmkyIu xpHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWRGMfAvUTgdiF/l6G//po8ZlyfF4lwa5tJ+fK6Ad0c=; b=BqlBHAvAgCcXoFTX0PgXU2mCAHnU2e5MsAu+iQRhg6OFYfIjtveieVqbnAV2JH8+1N DiO5wgnQCHiNDYZMZkDnoqKoS/FzfKqYmgCWUGQNIA4InuFcdKbKtFiYptxSywBzr9J5 U+XBNuqeJaluLdawRjdJ2lXrm9UVt7bck4mpo5+fDSRWrvbKgYhmMlJL6GkdNuPZ7axr TONnIX138KLAAJ0VBR/HqO5lncKXt8yc+VdcYXllDIjjscLA/C6Rxfk+PyciuPSD3b6K jqlgm/zpsyvah1/z0/kcX+9pkMvBeDIgbg4GydXdystaXS0jpWpfqWVfmQSgyFPIszyU c5Nw==
X-Gm-Message-State: AEkoousAGcu8wW0o4k4zviEo8QP3Iahy7EKIHhzIJAZqui4LOSFm9hh8PTZ9HzpoLp8ASw==
X-Received: by 10.200.42.153 with SMTP id b25mr45538292qta.72.1471442127462; Wed, 17 Aug 2016 06:55:27 -0700 (PDT)
Received: from [10.0.1.9] (dynamic-acs-24-154-119-181.zoominternet.net. [24.154.119.181]) by smtp.gmail.com with ESMTPSA id d38sm17837280qte.17.2016.08.17.06.55.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 06:55:26 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <067.033bb4c75a1be073bf1638fc7b12a580@tools.ietf.org>
Date: Wed, 17 Aug 2016 09:55:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <30567D6E-B654-4B0C-A8CB-4E8F4B180CBC@brianrosen.net>
References: <067.033bb4c75a1be073bf1638fc7b12a580@tools.ietf.org>
To: slim issue tracker 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: slim@ietf.org, =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #21 (negotiating-human-language): Add the text message modality to the realtime draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 13:55:47 -0000

I support adding text, but it should be sufficient to mention that the =
language tags can be applied to m=3Dmessage sections.

I wouldn=E2=80=99t want to assume anything about future modalities, but =
maybe we could say something along the lines of =E2=80=9CApplication of =
the humintlang tags to SDP sections where human understandable media in =
specific languages is sent, such as m=3Dapplication (e.g. WebRTC text =
media) or m=3Dmessage (MSRP) is permitted=E2=80=9D.  That might even =
cover something like a screen share where you might have slides in =
multiple media available.

I don=E2=80=99t want to be very explicit, so we can cover new media =
streams that have obvious meaning when we apply the tags without =
requiring every new m=3D to have text saying how this spec applies.=20

Brian

> On Aug 17, 2016, at 9:42 AM, slim issue tracker =
 wrote:
>=20
> #21: Add the text message modality to the realtime draft
>=20
> There is a modality that we have not discussed at all yet. That is the
> "text message" modality. It is not really interactive, but very often =
used
> together with interactive media in a kind of slow =
pseudo-conversational
> mode. One implementation is MSRP that is specified by the m=3Dmessage =
media.
> There seems to be some interest to extend our specification to handle =
that
> modality as well.
>=20
> Then the text message modality needs to be described and how it is
> implicitly identified in sdp both in the main media m=3Dmessage and in =
a
> subchannel of a data channel.
>=20
> --=20
> =
-------------------------------------+------------------------------------=
-
> Reporter:                           |      Owner:  draft-ietf-slim-
>  gunnar.hellstrom@omnitor.se        |  =
negotiating-human-language@ietf.org
>     Type:  enhancement              |     Status:  new
> Priority:  major                    |  Milestone:
> Component:  negotiating-human-       |    Version:
>  language                           |   Keywords:  message
> Severity:  In WG Last Call          |
> =
-------------------------------------+------------------------------------=
-
>=20
> Ticket URL: 
> slim 
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Wed Aug 17 07:13:59 2016
Return-Path: 
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 C70FF12DC22 for ; Wed, 17 Aug 2016 07:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 Y3uZaoCvfcVh for ; Wed, 17 Aug 2016 07:13:55 -0700 (PDT)
Received: from bin-vsp-out-03.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 BEC2F12DB76 for ; Wed, 17 Aug 2016 07:13:10 -0700 (PDT)
X-Halon-ID: b833da06-6484-11e6-88cf-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 17 Aug 2016 16:13:06 +0200 (CEST)
To: Brian Rosen 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se>
Date: Wed, 17 Aug 2016 16:13:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------011B6EB01D8A72EEFE721983"
Archived-At: 
Cc: Natasha Rooney , slim@ietf.org, slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 14:13:58 -0000

This is a multi-part message in MIME format.
--------------011B6EB01D8A72EEFE721983
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>
>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellström 
>> > wrote:
>>
>> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>>> I don’t think this is useful, and I think it’s beyond the consensus on what this document would contain.
>>>
>>> If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that English audio is most important doesn’t change your answer.  This is especially true with modality.  There is no way I can use advice of which modality is most important to you.  If you offer video, I answer with some video if I can do video.  If I can’t I won’t include a video answer.  Telling me you realty, really want video isn’t useful.
>> In some limited examples that would lead to successful call start.
>> But consider a couple of other simple cases:
>> A. Two common spoken languages:
>> I send an offer of spoken English and French in audio in both 
>> directions, and you have configured your device that you also know 
>> English and French in both directions.
>> Then, the protocol selects spoken English and puts that in the 
>> answer. In order for the call to complete successfully you then need 
>> to know that English both ways was selected, so that you start 
>> talking English in your answer. It would be a failure of our 
>> intentions if you only got a connected indication and needed to start 
>> asking me what language I prefer.
>> We do not specify how the information is conveyed to you, but it is.
> The protocol answer was English.  Both ends know that.  User interface 
> is out of scope.
Yes, user interface mechanisms are out of scope, but the intention of 
our work is not completed if the called user does not know the result of 
the negotiation ( in most cases ). So for this example we have the 
preference indication we need, and we can say that the user needs to 
know the result but the mechanism for that is out of scope.
>
>> Even if you knew French and Italian, you would need to know that the 
>> common language is French.
>>
>> B.  One spoken and one written language
>> I send an offer with spoken English in audio and written English in 
>> text. I call you, and you have also configured spoken English in 
>> audio and written English in text.
>> We both prefer to talk if we have a chance.
>> The negotiation succeeds and you get an indication that audio and 
>> text are the available media. If you do not get any preference 
>> indication, you do not know how to start the call. You may try 
>> English text fist and type "Hi, welcome, what can I do for you". I 
>> notice that you type, so I answer in text, because I do not know if 
>> you can talk English. We might continue the whole call in text, or 
>> take the effort to ask if we can change to talking.
>> Not until you get to know that we both can use spoken English and 
>> that it is the preferred match, you get a chance to respond in spoken 
>> English and the call starts well. The device can convey the 
>> negotiation result to you without us specifyinng how, but we need to 
>> describe that my preference for spoken modality is conveyed by the 
>> protocol.
> The protocol exchange informs BOTH ENDS that both voice and text is 
> negotiated.  It’s perfectly fine for either end to start in either 
> modality, and switch any time they want to.
No that is not perfectly fine. It is inconvenient and awkward to 
communicate in other than your favoured modality. And it is awkward to 
have a dialogue about what alternatives there are. A most simple 
mechanism to configure and convey the modality preference is needed as 
part of our protocol.

You can have even more examples where the solution is to both have a 
favoured modality indication and a way (not specified by us) to convey 
the result of the negotiation to the users.

Why shall we make a difference in conveying preference between languages 
in the same modality but not in different modalities? I do not see the 
logic in that.

/Gunnar


>
>>
>>
>> Many other examples can easily be constructed where we both need the 
>> preference between modalities and that the user get to know the 
>> result of the negotiation, or at least the best matching languages.
>>
>>> Please remember, we’re not designing user interfaces, we’re designing protocols.
>> Yes, we specify the protocol for conveying information about language 
>> and modality between the sides involved in the call.
>> In most cases some mechanism that we do not describe needs to take 
>> this information to the user so that the call can be completed 
>> successfully.
>> The other way - that the user is expected to configure the languages 
>> and modalities is briefly mentioned in the introduction by these words:
>>
>> "Since this is a protocol mechanism, the user equipment (UE client)
>>     needs to know the user's preferred languages; a reasonable technique
>>     could include a configuration mechanism with a default of the language of the user interface.â€
> That’s in scope, because it’s discussing configuration for the 
> protocol exchange.
Well, let us add favoured modality and we are done.
>> I suggest that we also say that "The result of the negotiation is expected to be provided to the user in most applications of this mechanism,
>> but it is out of scope to specify how this is done.â€
> That’s out of scope, that’s strictly user interface.
Can you propose a rewording that it matches your view.
>
>> That would not be specifying user interface but clarifying the main purpose.
>>
>> The paragraph in the introduction continues:
>>
>>     "In some cases, a UE could tie
>>     language and media preferences, such as a preference for a video
>>     stream using a signed language and/or a text or audio stream using a
>>     written/spoken language."
>>
>> I take this sentence as a promise that later in the document we will read how such preference between languages in different modalities
>> is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that.
> We can edit this text to remove the inference.
We need instead sharpen it and then explain how.

/Gunnar
>
>> It can be sufficient to add indication of the most preferred modality to the protocol, because within the modalities we have the order of the attributes as the preference order.
>>
>>
>>
>> Gunnar
>>
>>> Brian
>>>
>>>
>>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker  wrote:
>>>>
>>>> #8: Introduce a section on most favoured modality
>>>>
>>>>
>>>> Comment (bygunnar.hellstrom@omnitor.se):
>>>>
>>>> This is not anymore a fully specified preference level between languages
>>>> in different modalities. In this version it is just a single indication of
>>>> the most favoured modality ( and by that the most favoured language).
>>>>
>>>> It is such a small addition, and so urgently needed to make the draft
>>>> useful, that it should be allowed to be included.
>>>>
>>>> -- 
>>>> -------------------------------------+-------------------------------------
>>>> Reporter:                           |       Owner:  draft-ietf-slim-
>>>>   gunnar.hellstrom@omnitor.se         |negotiating-human-language@ietf.org
>>>>      Type:  enhancement              |      Status:  closed
>>>> Priority:  major                    |   Milestone:
>>>> Component:  negotiating-human-       |     Version:
>>>>   language                           |  Resolution:  wontfix
>>>> Severity:  In WG Last Call          |
>>>> Keywords:  modality                 |
>>>> -------------------------------------+-------------------------------------
>>>>
>>>> Ticket URL:
>>>> slim
>>>>
>>>> _______________________________________________
>>>> 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
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


--------------011B6EB01D8A72EEFE721983
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
Den 2016-08-17 kl. 15:35, skrev Brian
      Rosen:

    

    

      
      

      

        

          
          

          
Den 2016-08-16 kl. 23:50, skrev
              Brian Rosen:

            

              
I don’t think this is useful, and I think it’s beyond the consensus on what this document would contain.

If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that English audio is most important doesn’t change your answer.  This is especially true with modality.  There is no way I can use advice of which modality is most important to you.  If you offer video, I answer with some video if I can do video.  If I can’t I won’t include a video answer.  Telling me you realty, really want video isn’t useful.

            

            In some limited examples that would
              lead to successful call start. 

            But consider a couple of other
              simple cases:

            A. Two common spoken languages:

            I send an offer of spoken English
              and French in audio in both directions, and you have
              configured your device that you also know English and
              French in both directions. 

            Then, the protocol selects spoken
              English and puts that in the answer. In order for the call
              to complete successfully you then need to know that
              English both ways was selected, so that you start talking
              English in your answer. It would be a failure of our
              intentions if you only got a connected indication and
              needed to start asking me what language I prefer. 

            We do not specify how the
              information is conveyed to you, but it is.  

          

        

        The protocol answer was English.  Both ends know that.  User
        interface is out of scope.

    

    Yes, user interface mechanisms are out of scope, but the intention
    of our work is not completed if the called user does not know the
    result of the negotiation ( in most cases ). So for this example we
    have the preference indication we need, and we can say that the user
    needs to know the result but the mechanism for that is out of scope.

    

      


        

          
Even if you knew French and Italian,
              you would need to know that the common language is French.

            

            B.  One spoken and one written
              language

            I send an offer with spoken English
              in audio and written English in text. I call you, and you
              have also configured spoken English in audio and written
              English in text. 

            We both prefer to talk if we have a
              chance. 

            The negotiation succeeds and you get
              an indication that audio and text are the available media.
              If you do not get any preference indication, you do not
              know how to start the call. You may try English text fist
              and type "Hi, welcome, what can I do for you". I notice
              that you type, so I answer in text, because I do not know
              if you can talk English. We might continue the whole call
              in text, or take the effort to ask if we can change to
              talking. 

            Not until you get to know that we
              both can use spoken English and that it is the preferred
              match, you get a chance to respond in spoken English and
              the call starts well. The device can convey the
              negotiation result to you without us specifyinng how, but
              we need to describe that my preference for spoken modality
              is conveyed by the protocol.

          

        

        The protocol exchange informs BOTH ENDS that both voice and text
        is negotiated.  It’s perfectly fine for either end to start in
        either modality, and switch any time they want to.

    

    No that is not perfectly fine. It is inconvenient and awkward to
    communicate in other than your favoured modality. And it is awkward
    to have a dialogue about what alternatives there are. A most simple
    mechanism to configure and convey the modality preference is needed
    as part of our protocol.  

    

    You can have even more examples where the solution is to both have a
    favoured modality indication and a way (not specified by us) to
    convey the result of the negotiation to the users.

    

    Why shall we make a difference in conveying preference between
    languages in the same modality but not in different modalities? I do
    not see the logic in that.

    

    /Gunnar

    

     

    

      


        

          


              

            Many other examples can easily be
              constructed where we both need the preference between
              modalities and that the user get to know the result of the
              negotiation, or at least the best matching languages.

                

            

              
Please remember, we’re not designing user interfaces, we’re designing protocols.

            

            Yes, we specify the protocol for
              conveying information about language and modality between
              the sides involved in the call. 

            In most cases some mechanism that we
              do not describe needs to take this information to the user
              so that the call can be completed successfully. 

            The other way - that the user is
              expected to configure the languages and modalities is
              briefly mentioned in the introduction by these words:

            

            "Since this is a protocol mechanism,
              the user equipment (UE client)
            
   needs to know the user's preferred languages; a reasonable technique
   could include a configuration mechanism with a default of the language of the user interface.â€

          

        

        That’s in scope, because it’s discussing configuration for the
        protocol exchange.

      

    

    Well, let us add favoured modality and we are done.

    

      

        

          

            
I suggest that we also say that "The result of the negotiation is expected to be provided to the user in most applications of this mechanism, 
but it is out of scope to specify how this is done.â€


          

        

        That’s out of scope, that’s strictly user interface.

    

    Can you propose a rewording that it matches your view.

    

      


        

          

            
That would not be specifying user interface but clarifying the main purpose.

The paragraph in the introduction continues:

   "In some cases, a UE could tie
   language and media preferences, such as a preference for a video
   stream using a signed language and/or a text or audio stream using a
   written/spoken language."

I take this sentence as a promise that later in the document we will read how such preference between languages in different modalities 
is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that. 


          

        

        We can edit this text to remove the inference.

    

    We need instead sharpen it and then explain how.  

    

    /Gunnar

    

      


        

          

            
It can be sufficient to add indication of the most preferred modality to the protocol, because within the modalities we have the order of the attributes as the preference order. 



Gunnar



            

              
Brian




              

                
On Aug 16, 2016, at 5:36 PM, slim issue tracker <trac+slim@tools.ietf.org> wrote:

#8: Introduce a section on most favoured modality


Comment (by gunnar.hellstrom@omnitor.se):

This is not anymore a fully specified preference level between languages
in different modalities. In this version it is just a single indication of
the most favoured modality ( and by that the most favoured language).

It is such a small addition, and so urgently needed to make the draft
useful, that it should be allowed to be included.

-- 
-------------------------------------+-------------------------------------
Reporter:                           |       Owner:  draft-ietf-slim-
 gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
    Type:  enhancement              |      Status:  closed
Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
 language                           |  Resolution:  wontfix
Severity:  In WG Last Call          |
Keywords:  modality                 |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
slim <https://tools.ietf.org/slim/>

_______________________________________________
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

          

        

      

      

    

    

    
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  


--------------011B6EB01D8A72EEFE721983--


From nobody Wed Aug 17 07:26:05 2016
Return-Path: 
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 499F212DD70 for ; Wed, 17 Aug 2016 07:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 WIzYNh17FiuN for ; Wed, 17 Aug 2016 07:26:02 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BDC12DD5A for ; Wed, 17 Aug 2016 07:25:50 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id v123so101435613qkh.2 for ; Wed, 17 Aug 2016 07:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pnsyxgx7VeNurnfx6wDGeGQhulC2XJmAtSCTcBXxAGw=; b=GDadqU1sZnPqV/3XlYSM3dRprg2QP+/Odr9RxBFMfi/Z1UQSaWRnFaf8SmuZVwy9KW EF6wlKl7nprcwzw1KwzHaeJuWL2gsZGfVSHXEk7PR4F2qfxJl5Le8glv1XMjpC9zb1B1 yvf6vLlJC6n5jLHDWvaDwvZf9gsZVYilEj8GRMOTlB2GY9LXSWvt7Ov9iEIa6jfvLVVZ aEEDCfFra+RQnQxWjq8L4fQWYep34ITqf/lNlU27o20uNAW36bSM1YhyxXi568lkvjWo PDEmI4KP3ecqurLDuLklb5RhRKVedvYMN/h7y0HswIr8WehohY8B8gK96aPspyaffxyn RijQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pnsyxgx7VeNurnfx6wDGeGQhulC2XJmAtSCTcBXxAGw=; b=MMLtImMR5R4Anembu1jOl3ujnJ5S9v+L2oXsr4TkWw7lYXJJ1I+VPlxMYcBWtOaj+w rLO1z0LbF8OE1mCIwD5GKdEfdsJr69vTHUV3Qva6CqgngdyNVTuqm213sgMraYXfj46L yXUQQY2211m0ZdXLoG5CYA/cUanko1YdZhr5vondHy53pBYvAkpMEO9MWUprfsxXckx5 C6kyoqvifV4thuJXgEBcta0Chd+MJO1KY0HNK7YrMOuSZMwPlEgqvznAn3gCCjHkEhUM XX0uDUxXXj3ivniFQ+lT2lk5qFslxJqQpCjLrTvo3mAFnLXg6QXBTX4CR6ZaHSP2DjV7 6Dxw==
X-Gm-Message-State: AEkoouu0AZB4jUtr/UN8E23+oi7hUZ9pleke0a0y25OPJKx66LQk5LnbmkTIFly8n89i7g==
X-Received: by 10.55.78.17 with SMTP id c17mr41520577qkb.168.1471443949413; Wed, 17 Aug 2016 07:25:49 -0700 (PDT)
Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 1sm16648338qkj.42.2016.08.17.07.25.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 07:25:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_04251BCB-9F1C-46BE-BADE-D1948203222E"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se>
Date: Wed, 17 Aug 2016 10:25:46 -0400
Message-Id: <343679B4-E3FA-4BE4-A718-23457DE209CD@brianrosen.net>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net> <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Natasha Rooney , slim@ietf.org, slim issue tracker , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 14:26:04 -0000

--Apple-Mail=_04251BCB-9F1C-46BE-BADE-D1948203222E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

When you walk up to someone, and you both know more than one language, =
how do you start?=20

We=E2=80=99re actually very good at figuring out that kind of thing and =
we don=E2=80=99t need a lot of help to do it.

I=E2=80=99m not at all worried about humans figuring out what to do as =
long as we get calls to people who actually can understand the languages =
the caller prefers.

I=E2=80=99m very, very suspicious of things that make assumptions about =
user interface.  You are making lots of assumptions.  One of them is =
that there is a human answering the call.  That is NOT something we =
should assume.  Automatons behave differently than humans.  That=E2=80=99s=
 sometimes bad, but it=E2=80=99s sometimes good.

I=E2=80=99m also against being a specification nanny.  Just as there are =
no protocol police, there are no user interface police, and it may NOT =
be the right thing to tell a user what the other guy=E2=80=99s modality =
choice is. =20

Brian


> On Aug 17, 2016, at 10:13 AM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
>=20
>=20
> Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>>=20
>>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=C3=B6m =
> =
wrote:
>>>=20
>>> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>>>> I don=E2=80=99t think this is useful, and I think it=E2=80=99s =
beyond the consensus on what this document would contain.
>>>>=20
>>>> If I send an offer of English audio and you can do it, then you =
will send an answer with English audio.  If you can=E2=80=99t do it, =
then your answer won=E2=80=99t include English audio.  Me telling you =
that English audio is most important doesn=E2=80=99t change your answer. =
 This is especially true with modality.  There is no way I can use =
advice of which modality is most important to you.  If you offer video, =
I answer with some video if I can do video.  If I can=E2=80=99t I =
won=E2=80=99t include a video answer.  Telling me you realty, really =
want video isn=E2=80=99t useful.
>>> In some limited examples that would lead to successful call start.=20=

>>> But consider a couple of other simple cases:
>>> A. Two common spoken languages:
>>> I send an offer of spoken English and French in audio in both =
directions, and you have configured your device that you also know =
English and French in both directions.=20
>>> Then, the protocol selects spoken English and puts that in the =
answer. In order for the call to complete successfully you then need to =
know that English both ways was selected, so that you start talking =
English in your answer. It would be a failure of our intentions if you =
only got a connected indication and needed to start asking me what =
language I prefer.=20
>>> We do not specify how the information is conveyed to you, but it is. =
=20
>> The protocol answer was English.  Both ends know that.  User =
interface is out of scope.
> Yes, user interface mechanisms are out of scope, but the intention of =
our work is not completed if the called user does not know the result of =
the negotiation ( in most cases ). So for this example we have the =
preference indication we need, and we can say that the user needs to =
know the result but the mechanism for that is out of scope.
>>=20
>>> Even if you knew French and Italian, you would need to know that the =
common language is French.
>>>=20
>>> B.  One spoken and one written language
>>> I send an offer with spoken English in audio and written English in =
text. I call you, and you have also configured spoken English in audio =
and written English in text.=20
>>> We both prefer to talk if we have a chance.=20
>>> The negotiation succeeds and you get an indication that audio and =
text are the available media. If you do not get any preference =
indication, you do not know how to start the call. You may try English =
text fist and type "Hi, welcome, what can I do for you". I notice that =
you type, so I answer in text, because I do not know if you can talk =
English. We might continue the whole call in text, or take the effort to =
ask if we can change to talking.=20
>>> Not until you get to know that we both can use spoken English and =
that it is the preferred match, you get a chance to respond in spoken =
English and the call starts well. The device can convey the negotiation =
result to you without us specifyinng how, but we need to describe that =
my preference for spoken modality is conveyed by the protocol.
>> The protocol exchange informs BOTH ENDS that both voice and text is =
negotiated.  It=E2=80=99s perfectly fine for either end to start in =
either modality, and switch any time they want to.
> No that is not perfectly fine. It is inconvenient and awkward to =
communicate in other than your favoured modality. And it is awkward to =
have a dialogue about what alternatives there are. A most simple =
mechanism to configure and convey the modality preference is needed as =
part of our protocol. =20
>=20
> You can have even more examples where the solution is to both have a =
favoured modality indication and a way (not specified by us) to convey =
the result of the negotiation to the users.
>=20
> Why shall we make a difference in conveying preference between =
languages in the same modality but not in different modalities? I do not =
see the logic in that.
>=20
> /Gunnar
>=20
> =20
>>=20
>>>=20
>>>  =20
>>> Many other examples can easily be constructed where we both need the =
preference between modalities and that the user get to know the result =
of the negotiation, or at least the best matching languages.
>>>    =20
>>>> Please remember, we=E2=80=99re not designing user interfaces, =
we=E2=80=99re designing protocols.
>>> Yes, we specify the protocol for conveying information about =
language and modality between the sides involved in the call.=20
>>> In most cases some mechanism that we do not describe needs to take =
this information to the user so that the call can be completed =
successfully.=20
>>> The other way - that the user is expected to configure the languages =
and modalities is briefly mentioned in the introduction by these words:
>>>=20
>>> "Since this is a protocol mechanism, the user equipment (UE client)
>>>    needs to know the user's preferred languages; a reasonable =
technique
>>>    could include a configuration mechanism with a default of the =
language of the user interface.=E2=80=9D
>> That=E2=80=99s in scope, because it=E2=80=99s discussing =
configuration for the protocol exchange.
> Well, let us add favoured modality and we are done.
>>> I suggest that we also say that "The result of the negotiation is =
expected to be provided to the user in most applications of this =
mechanism,=20
>>> but it is out of scope to specify how this is done.=E2=80=9D
>> That=E2=80=99s out of scope, that=E2=80=99s strictly user interface.
> Can you propose a rewording that it matches your view.
>>=20
>>> That would not be specifying user interface but clarifying the main =
purpose.
>>>=20
>>> The paragraph in the introduction continues:
>>>=20
>>>    "In some cases, a UE could tie
>>>    language and media preferences, such as a preference for a video
>>>    stream using a signed language and/or a text or audio stream =
using a
>>>    written/spoken language."
>>>=20
>>> I take this sentence as a promise that later in the document we will =
read how such preference between languages in different modalities=20
>>> is coded and conveyed between the UEs. Our work is not complete and =
does not do its job until we have specified a mechanism for that.=20
>> We can edit this text to remove the inference.
> We need instead sharpen it and then explain how. =20
>=20
> /Gunnar
>>=20
>>> It can be sufficient to add indication of the most preferred =
modality to the protocol, because within the modalities we have the =
order of the attributes as the preference order.=20
>>>=20
>>>=20
>>>=20
>>> Gunnar
>>>=20
>>>> Brian
>>>>=20
>>>>=20
>>>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker =
  wrote:
>>>>>=20
>>>>> #8: Introduce a section on most favoured modality
>>>>>=20
>>>>>=20
>>>>> Comment (by gunnar.hellstrom@omnitor.se =
):
>>>>>=20
>>>>> This is not anymore a fully specified preference level between =
languages
>>>>> in different modalities. In this version it is just a single =
indication of
>>>>> the most favoured modality ( and by that the most favoured =
language).
>>>>>=20
>>>>> It is such a small addition, and so urgently needed to make the =
draft
>>>>> useful, that it should be allowed to be included.
>>>>>=20
>>>>> --=20
>>>>> =
-------------------------------------+------------------------------------=
-
>>>>> Reporter:                           |       Owner:  =
draft-ietf-slim-
>>>>>  gunnar.hellstrom@omnitor.se   =
      |  negotiating-human-language@ietf.org =

>>>>>     Type:  enhancement              |      Status:  closed
>>>>> Priority:  major                    |   Milestone:
>>>>> Component:  negotiating-human-       |     Version:
>>>>>  language                           |  Resolution:  wontfix
>>>>> Severity:  In WG Last Call          |
>>>>> Keywords:  modality                 |
>>>>> =
-------------------------------------+------------------------------------=
-
>>>>>=20
>>>>> Ticket URL: =
 =

>>>>> slim  
>>>>>=20
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> SLIM@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/slim =

>>>=20
>>> --=20
>>> -----------------------------------------
>>> Gunnar Hellstr=C3=B6m
>>> Omnitor
>>> gunnar.hellstrom@omnitor.se 
>>> +46 708 204 288
>>=20
>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288


--Apple-Mail=_04251BCB-9F1C-46BE-BADE-D1948203222E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

When you walk up to someone, and you both know more than one =
language, how do you start? 

We=E2=80=99re actually very good at figuring out that kind =
of thing and we don=E2=80=99t need a lot of help to do it.

I=E2=80=99m not at all =
worried about humans figuring out what to do as long as we get calls to =
people who actually can understand the languages the caller =
prefers.

I=E2=80=
=99m very, very suspicious of things that make assumptions about user =
interface.  You are making lots of assumptions.  One of them =
is that there is a human answering the call.  That is NOT something =
we should assume.  Automatons behave differently than humans. =
 That=E2=80=99s sometimes bad, but it=E2=80=99s sometimes =
good.

I=E2=80=99=
m also against being a specification nanny.  Just as there are no =
protocol police, there are no user interface police, and it may NOT be =
the right thing to tell a user what the other guy=E2=80=99s modality =
choice is.  

Brian


On Aug 17, 2016, at 10:13 AM, =
Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:


 =20
    
 =20
  


    

    

    
Den 2016-08-17 kl. 15:35, skrev Brian
      Rosen:

    

    

      
      

      

        

          
On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=C3=B6=
m
            <gunnar.hellstrom@omnitor.se>
            wrote:

          

          
Den 2016-08-16 kl. 23:50, skrev
              Brian Rosen:

            

              
I don=E2=80=99t think this is =
useful, and I think it=E2=80=99s beyond the consensus on what this =
document would contain.

If I send an offer of English audio and you can do it, then you will =
send an answer with English audio.  If you can=E2=80=99t do it, then =
your answer won=E2=80=99t include English audio.  Me telling you that =
English audio is most important doesn=E2=80=99t change your answer.  =
This is especially true with modality.  There is no way I can use advice =
of which modality is most important to you.  If you offer video, I =
answer with some video if I can do video.  If I can=E2=80=99t I won=E2=80=99=
t include a video answer.  Telling me you realty, really want video =
isn=E2=80=99t useful.

            

            In some limited examples that =
would
              lead to successful call start. 

            But consider a couple of other
              simple cases:

            A. Two common spoken =
languages:

            I send an offer of spoken English
              and French in audio in both directions, and you have
              configured your device that you also know English and
              French in both directions. 

            Then, the protocol selects spoken
              English and puts that in the answer. In order for the call
              to complete successfully you then need to know that
              English both ways was selected, so that you start talking
              English in your answer. It would be a failure of our
              intentions if you only got a connected indication and
              needed to start asking me what language I prefer. 

            We do not specify how the
              information is conveyed to you, but it is.  

          

        

        The protocol answer was English.  Both ends know that. =
 User
        interface is out of scope.

    

    Yes, user interface mechanisms are out of scope, but the intention
    of our work is not completed if the called user does not know the
    result of the negotiation ( in most cases ). So for this example we
    have the preference indication we need, and we can say that the user
    needs to know the result but the mechanism for that is out of =
scope.

    

      


        

          
Even if you knew French and =
Italian,
              you would need to know that the common language is =
French.

            

            B.  One spoken and one =
written
              language

            I send an offer with spoken =
English
              in audio and written English in text. I call you, and you
              have also configured spoken English in audio and written
              English in text. 

            We both prefer to talk if we have =
a
              chance. 

            The negotiation succeeds and you =
get
              an indication that audio and text are the available media.
              If you do not get any preference indication, you do not
              know how to start the call. You may try English text fist
              and type "Hi, welcome, what can I do for you". I notice
              that you type, so I answer in text, because I do not know
              if you can talk English. We might continue the whole call
              in text, or take the effort to ask if we can change to
              talking. 

            Not until you get to know that we
              both can use spoken English and that it is the preferred
              match, you get a chance to respond in spoken English and
              the call starts well. The device can convey the
              negotiation result to you without us specifyinng how, but
              we need to describe that my preference for spoken modality
              is conveyed by the protocol.

          

        

        The protocol exchange informs BOTH ENDS that both voice and text
        is negotiated.  It=E2=80=99s perfectly fine for either end =
to start in
        either modality, and switch any time they want to.

    

    No that is not perfectly fine. It is inconvenient and awkward to
    communicate in other than your favoured modality. And it is awkward
    to have a dialogue about what alternatives there are. A most simple
    mechanism to configure and convey the modality preference is needed
    as part of our protocol.  

    

    You can have even more examples where the solution is to both have a
    favoured modality indication and a way (not specified by us) to
    convey the result of the negotiation to the users.

    

    Why shall we make a difference in conveying preference between
    languages in the same modality but not in different modalities? I do
    not see the logic in that.

    

    /Gunnar

    

     

    

      


        

          


              

            Many other examples can easily be
              constructed where we both need the preference between
              modalities and that the user get to know the result of the
              negotiation, or at least the best matching =
languages.

                

            

              
Please remember, we=E2=80=99re =
not designing user interfaces, we=E2=80=99re designing protocols.

            

            Yes, we specify the protocol for
              conveying information about language and modality between
              the sides involved in the call. 

            In most cases some mechanism that =
we
              do not describe needs to take this information to the user
              so that the call can be completed successfully. 

            The other way - that the user is
              expected to configure the languages and modalities is
              briefly mentioned in the introduction by these =
words:

            

            "Since this is a protocol =
mechanism,
              the user equipment (UE client)
            
   needs to know the user's preferred languages; a reasonable =
technique
   could include a configuration mechanism with a default of the =
language of the user interface.=E2=80=9D

          

        

        That=E2=80=99s in scope, because it=E2=80=99s discussing =
configuration for the
        protocol exchange.

      

    

    Well, let us add favoured modality and we are done.

    

      

        

          

            
I suggest that we also say that "The result of the negotiation is =
expected to be provided to the user in most applications of this =
mechanism,=20
but it is out of scope to specify how this is done.=E2=80=9D


          

        

        That=E2=80=99s out of scope, that=E2=80=99s strictly user =
interface.

    

    Can you propose a rewording that it matches your view.

    

      


        

          

            
That would not be specifying user interface but clarifying the main =
purpose.

The paragraph in the introduction continues:

   "In some cases, a UE could tie
   language and media preferences, such as a preference for a video
   stream using a signed language and/or a text or audio stream using a
   written/spoken language."

I take this sentence as a promise that later in the document we will =
read how such preference between languages in different modalities=20
is coded and conveyed between the UEs. Our work is not complete and does =
not do its job until we have specified a mechanism for that.=20


          

        

        We can edit this text to remove the inference.

    

    We need instead sharpen it and then explain how.  
=

    

    /Gunnar

    

      


        

          

            
It can be sufficient to add indication of the most preferred =
modality to the protocol, because within the modalities we have the =
order of the attributes as the preference order.=20



Gunnar



            

              
Brian




              

                
On Aug 16, 2016, at 5:36 PM, =
slim issue tracker <trac+slim@tools.ietf.org><=
/a> wrote:

#8: Introduce a section on most favoured modality


Comment (by gunnar.hellstrom@omnitor.se):

This is not anymore a fully specified preference level between languages
in different modalities. In this version it is just a single indication =
of
the most favoured modality ( and by that the most favoured language).

It is such a small addition, and so urgently needed to make the draft
useful, that it should be allowed to be included.

--=20
=
-------------------------------------+------------------------------------=
-
Reporter:                           |       Owner:  draft-ietf-slim-
 gunnar.hellstrom@omnitor.se        |  negotiating-human-lang=
uage@ietf.org
    Type:  enhancement              |      Status:  closed
Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
 language                           |  Resolution:  wontfix
Severity:  In WG Last Call          |
Keywords:  modality                 |
=
-------------------------------------+------------------------------------=
-

Ticket URL: <h=
ttps://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
slim <https://tools.ietf.org/slim/>=


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m=
ailman/listinfo/slim


              

            

            

            
--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

          

        

      

      

    

    

    
--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  




=

--Apple-Mail=_04251BCB-9F1C-46BE-BADE-D1948203222E--


From nobody Wed Aug 17 08:03:51 2016
Return-Path: 
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 6DFA212DFA4 for ; Wed, 17 Aug 2016 08:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 B_Wl8cmRizHI for ; Wed, 17 Aug 2016 08:03:47 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 8704B12DF3A for ; Wed, 17 Aug 2016 08:03:47 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-11v.sys.comcast.net with SMTP id a2JbbpfnClSxsa2Neb0SXf; Wed, 17 Aug 2016 15:03:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with SMTP id a2NdbVxWP9tiLa2Neby9T4; Wed, 17 Aug 2016 15:03:46 +0000
To: slim@ietf.org
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net> <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se> <343679B4-E3FA-4BE4-A718-23457DE209CD@brianrosen.net>
From: Paul Kyzivat 
Message-ID: <9e9b66a2-08dc-faa6-eaad-7bda32975483@alum.mit.edu>
Date: Wed, 17 Aug 2016 11:03:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <343679B4-E3FA-4BE4-A718-23457DE209CD@brianrosen.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfEuNEz80gHzESmAZrTj2DhOaisiQtEQieIgbLYbV2E9l8WvIziIajOi5VeGqZlJXtXnpZ7GdIvXacYjwxasscJBBMmeN850w6D33zhWYgqpM8r2+kW2c 1P4mv3pg4A/4bAQvNbpZL7BufgOxbx/WgtX2pG3BTOUhra3PS558gZcLbrJ9z3btj0jR3Ah5Mj1RhA==
Archived-At: 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 15:03:49 -0000

In general I think I agree with you. But I want to ensure we are getting 
to a place where we will be able to dispense with the "Press 1 if you 
speak Spanish".

When I call a call center I want to be directed automatically to someone 
who speaks my language and then be greeted in a language I speak.

	Thanks,
	Paul

On 8/17/16 10:25 AM, Brian Rosen wrote:
> When you walk up to someone, and you both know more than one language,
> how do you start?
>
> We’re actually very good at figuring out that kind of thing and we don’t
> need a lot of help to do it.
>
> I’m not at all worried about humans figuring out what to do as long as
> we get calls to people who actually can understand the languages the
> caller prefers.
>
> I’m very, very suspicious of things that make assumptions about user
> interface.  You are making lots of assumptions.  One of them is that
> there is a human answering the call.  That is NOT something we should
> assume.  Automatons behave differently than humans.  That’s sometimes
> bad, but it’s sometimes good.
>
> I’m also against being a specification nanny.  Just as there are no
> protocol police, there are no user interface police, and it may NOT be
> the right thing to tell a user what the other guy’s modality choice is.
>
> Brian
>
>
>> On Aug 17, 2016, at 10:13 AM, Gunnar Hellström
>> > wrote:
>>
>>
>>
>> Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>>>
>>>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellström
>>>> >
>>>> wrote:
>>>>
>>>> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>>>>> I don’t think this is useful, and I think it’s beyond the consensus on what this document would contain.
>>>>>
>>>>> If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that English audio is most important doesn’t change your answer.  This is especially true with modality.  There is no way I can use advice of which modality is most important to you.  If you offer video, I answer with some video if I can do video.  If I can’t I won’t include a video answer.  Telling me you realty, really want video isn’t useful.
>>>> In some limited examples that would lead to successful call start.
>>>> But consider a couple of other simple cases:
>>>> A. Two common spoken languages:
>>>> I send an offer of spoken English and French in audio in both
>>>> directions, and you have configured your device that you also know
>>>> English and French in both directions.
>>>> Then, the protocol selects spoken English and puts that in the
>>>> answer. In order for the call to complete successfully you then need
>>>> to know that English both ways was selected, so that you start
>>>> talking English in your answer. It would be a failure of our
>>>> intentions if you only got a connected indication and needed to
>>>> start asking me what language I prefer.
>>>> We do not specify how the information is conveyed to you, but it is.
>>> The protocol answer was English.  Both ends know that.  User
>>> interface is out of scope.
>> Yes, user interface mechanisms are out of scope, but the intention of
>> our work is not completed if the called user does not know the result
>> of the negotiation ( in most cases ). So for this example we have the
>> preference indication we need, and we can say that the user needs to
>> know the result but the mechanism for that is out of scope.
>>>
>>>> Even if you knew French and Italian, you would need to know that the
>>>> common language is French.
>>>>
>>>> B.  One spoken and one written language
>>>> I send an offer with spoken English in audio and written English in
>>>> text. I call you, and you have also configured spoken English in
>>>> audio and written English in text.
>>>> We both prefer to talk if we have a chance.
>>>> The negotiation succeeds and you get an indication that audio and
>>>> text are the available media. If you do not get any preference
>>>> indication, you do not know how to start the call. You may try
>>>> English text fist and type "Hi, welcome, what can I do for you". I
>>>> notice that you type, so I answer in text, because I do not know if
>>>> you can talk English. We might continue the whole call in text, or
>>>> take the effort to ask if we can change to talking.
>>>> Not until you get to know that we both can use spoken English and
>>>> that it is the preferred match, you get a chance to respond in
>>>> spoken English and the call starts well. The device can convey the
>>>> negotiation result to you without us specifyinng how, but we need to
>>>> describe that my preference for spoken modality is conveyed by the
>>>> protocol.
>>> The protocol exchange informs BOTH ENDS that both voice and text is
>>> negotiated.  It’s perfectly fine for either end to start in either
>>> modality, and switch any time they want to.
>> No that is not perfectly fine. It is inconvenient and awkward to
>> communicate in other than your favoured modality. And it is awkward to
>> have a dialogue about what alternatives there are. A most simple
>> mechanism to configure and convey the modality preference is needed as
>> part of our protocol.
>>
>> You can have even more examples where the solution is to both have a
>> favoured modality indication and a way (not specified by us) to convey
>> the result of the negotiation to the users.
>>
>> Why shall we make a difference in conveying preference between
>> languages in the same modality but not in different modalities? I do
>> not see the logic in that.
>>
>> /Gunnar
>>
>>
>>>
>>>>
>>>>
>>>> Many other examples can easily be constructed where we both need the
>>>> preference between modalities and that the user get to know the
>>>> result of the negotiation, or at least the best matching languages.
>>>>
>>>>> Please remember, we’re not designing user interfaces, we’re designing protocols.
>>>> Yes, we specify the protocol for conveying information about
>>>> language and modality between the sides involved in the call.
>>>> In most cases some mechanism that we do not describe needs to take
>>>> this information to the user so that the call can be completed
>>>> successfully.
>>>> The other way - that the user is expected to configure the languages
>>>> and modalities is briefly mentioned in the introduction by these words:
>>>>
>>>> "Since this is a protocol mechanism, the user equipment (UE client)
>>>>    needs to know the user's preferred languages; a reasonable technique
>>>>    could include a configuration mechanism with a default of the language of the user interface.”
>>> That’s in scope, because it’s discussing configuration for the
>>> protocol exchange.
>> Well, let us add favoured modality and we are done.
>>>> I suggest that we also say that "The result of the negotiation is expected to be provided to the user in most applications of this mechanism,
>>>> but it is out of scope to specify how this is done.”
>>> That’s out of scope, that’s strictly user interface.
>> Can you propose a rewording that it matches your view.
>>>
>>>> That would not be specifying user interface but clarifying the main purpose.
>>>>
>>>> The paragraph in the introduction continues:
>>>>
>>>>    "In some cases, a UE could tie
>>>>    language and media preferences, such as a preference for a video
>>>>    stream using a signed language and/or a text or audio stream using a
>>>>    written/spoken language."
>>>>
>>>> I take this sentence as a promise that later in the document we will read how such preference between languages in different modalities
>>>> is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that.
>>> We can edit this text to remove the inference.
>> We need instead sharpen it and then explain how.
>>
>> /Gunnar
>>>
>>>> It can be sufficient to add indication of the most preferred modality to the protocol, because within the modalities we have the order of the attributes as the preference order.
>>>>
>>>>
>>>>
>>>> Gunnar
>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker  wrote:
>>>>>>
>>>>>> #8: Introduce a section on most favoured modality
>>>>>>
>>>>>>
>>>>>> Comment (by gunnar.hellstrom@omnitor.se):
>>>>>>
>>>>>> This is not anymore a fully specified preference level between languages
>>>>>> in different modalities. In this version it is just a single indication of
>>>>>> the most favoured modality ( and by that the most favoured language).
>>>>>>
>>>>>> It is such a small addition, and so urgently needed to make the draft
>>>>>> useful, that it should be allowed to be included.
>>>>>>
>>>>>> --
>>>>>> -------------------------------------+-------------------------------------
>>>>>> Reporter:                           |       Owner:  draft-ietf-slim-
>>>>>>  gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
>>>>>>     Type:  enhancement              |      Status:  closed
>>>>>> Priority:  major                    |   Milestone:
>>>>>> Component:  negotiating-human-       |     Version:
>>>>>>  language                           |  Resolution:  wontfix
>>>>>> Severity:  In WG Last Call          |
>>>>>> Keywords:  modality                 |
>>>>>> -------------------------------------+-------------------------------------
>>>>>>
>>>>>> Ticket URL: 
>>>>>> slim 
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Wed Aug 17 10:36:36 2016
Return-Path: 
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 E6C2C12DB07 for ; Wed, 17 Aug 2016 10:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 FB1PB0EFfXtx for ; Wed, 17 Aug 2016 10:36:30 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A197612DB9D for ; Wed, 17 Aug 2016 10:36:29 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id l2so106632946qkf.3 for ; Wed, 17 Aug 2016 10:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=aYXENgtHDx3LyxdKszluzR80uT5ItSpINvqjlYEYPPc=; b=nuF9vLWFxU2adKxVJdYdFvOnhwc/psuDpxbeLgNgVXoRARcncQhwM6/BIHGA4MTCP9 uaFMuwjW5HmwIA5z5YbM6f4fcczxzB9BP6kvH/ZBqa02kpBOiee+Or3z9BjGxe7I5gp4 r0HLnnFK7TnZug13fmUMx0crjD0rIm6QqpTJrUbuDNyvolsWnUsHmJdzvbe7ol/sBq5L h0rhBxEQ6X+o2oXwyQQOdB8k5gzX3AHRpl1l0efG2oKIt1wPqvJkv5eGwyMr+dIFzP2b pZm3ZPoc6ZmnD+wZiTDvT8ljir9WKO/DVS/KsSP629tIwhlSKBhvR2KYw/28t+i5cUG3 r4nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aYXENgtHDx3LyxdKszluzR80uT5ItSpINvqjlYEYPPc=; b=VSZC+zq93vVrYrKHBMt3DjTD0/P3yiqp3UZO774xdYNqi0fGIw0ZCUc57JD5TlZPUT ep8YSkgiXfbJNSqt6Auml151KRA4AEh2a4OV5Y3LVQmgmn2D/Pnn4vBP1KLjTAhqdzTE eOFTSVG9hsRRXv+dqI4o8ogCJgXedy0422AG3k81zP9V6kAKlPO4YAy2pfJYc4rQWsFY iHErxGtiJfUuWqmG5DifIZLuX6ldCmbJ6+tCSbc6uLEwBqsdaRsylcLoi+eWbnscrc4Y muns6Al2twVriyfZ6ddL1W31vNDhOv2/6pdKW3J6EhbPW2jBzunhuxgZGsooZTX4xM1r v12w==
X-Gm-Message-State: AEkoouuAgA9KWrDuvdJJdrCU8bSQKOSquRyZgzexxh8HE6j8JGWJoV734Hj7PStzqxP2jg==
X-Received: by 10.233.239.132 with SMTP id d126mr7328691qkg.122.1471455388651;  Wed, 17 Aug 2016 10:36:28 -0700 (PDT)
Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id a63sm17035477qkb.26.2016.08.17.10.36.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 10:36:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F87A5C0F-504D-48C8-B6B3-6C9A02CB7C83"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <9e9b66a2-08dc-faa6-eaad-7bda32975483@alum.mit.edu>
Date: Wed, 17 Aug 2016 13:36:25 -0400
Message-Id: <82D9611D-573B-4A13-96C4-6352B1EFEBE7@brianrosen.net>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net> <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se> <343679B4-E3FA-4BE4-A718-23457DE209CD@brianrosen.net> <9e9b66a2-08dc-faa6-eaad-7bda32975483@alum.mit.edu>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 17:36:34 -0000

--Apple-Mail=_F87A5C0F-504D-48C8-B6B3-6C9A02CB7C83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Absolutely, that=92s one of my goals.  You indicate your preference for =
Spanish, and we route your call to a Spanish speaker.  We know we=92ve =
negotiated Spanish, so if the call taker is bilingual, the UI could show =
them what was negotiated.  Furthermore, if we need to send the call to =
an IVR, the IVR knows what was negotiated and thus plays the right =
prompts, which is an example where there is  no UI (on the call =
answering side).

Brian

> On Aug 17, 2016, at 11:03 AM, Paul Kyzivat  =
wrote:
>=20
> In general I think I agree with you. But I want to ensure we are =
getting to a place where we will be able to dispense with the "Press 1 =
if you speak Spanish".
>=20
> When I call a call center I want to be directed automatically to =
someone who speaks my language and then be greeted in a language I =
speak.
>=20
> 	Thanks,
> 	Paul
>=20
> On 8/17/16 10:25 AM, Brian Rosen wrote:
>> When you walk up to someone, and you both know more than one =
language,
>> how do you start?
>>=20
>> We=92re actually very good at figuring out that kind of thing and we =
don=92t
>> need a lot of help to do it.
>>=20
>> I=92m not at all worried about humans figuring out what to do as long =
as
>> we get calls to people who actually can understand the languages the
>> caller prefers.
>>=20
>> I=92m very, very suspicious of things that make assumptions about =
user
>> interface.  You are making lots of assumptions.  One of them is that
>> there is a human answering the call.  That is NOT something we should
>> assume.  Automatons behave differently than humans.  That=92s =
sometimes
>> bad, but it=92s sometimes good.
>>=20
>> I=92m also against being a specification nanny.  Just as there are no
>> protocol police, there are no user interface police, and it may NOT =
be
>> the right thing to tell a user what the other guy=92s modality choice =
is.
>>=20
>> Brian
>>=20
>>=20
>>> On Aug 17, 2016, at 10:13 AM, Gunnar Hellstr=F6m
>>>  =
>> wrote:
>>>=20
>>>=20
>>>=20
>>> Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>>>>=20
>>>>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=F6m
>>>>>  =
>>
>>>>> wrote:
>>>>>=20
>>>>> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>>>>>> I don=92t think this is useful, and I think it=92s beyond the =
consensus on what this document would contain.
>>>>>>=20
>>>>>> If I send an offer of English audio and you can do it, then you =
will send an answer with English audio.  If you can=92t do it, then your =
answer won=92t include English audio.  Me telling you that English audio =
is most important doesn=92t change your answer.  This is especially true =
with modality.  There is no way I can use advice of which modality is =
most important to you.  If you offer video, I answer with some video if =
I can do video.  If I can=92t I won=92t include a video answer.  Telling =
me you realty, really want video isn=92t useful.
>>>>> In some limited examples that would lead to successful call start.
>>>>> But consider a couple of other simple cases:
>>>>> A. Two common spoken languages:
>>>>> I send an offer of spoken English and French in audio in both
>>>>> directions, and you have configured your device that you also know
>>>>> English and French in both directions.
>>>>> Then, the protocol selects spoken English and puts that in the
>>>>> answer. In order for the call to complete successfully you then =
need
>>>>> to know that English both ways was selected, so that you start
>>>>> talking English in your answer. It would be a failure of our
>>>>> intentions if you only got a connected indication and needed to
>>>>> start asking me what language I prefer.
>>>>> We do not specify how the information is conveyed to you, but it =
is.
>>>> The protocol answer was English.  Both ends know that.  User
>>>> interface is out of scope.
>>> Yes, user interface mechanisms are out of scope, but the intention =
of
>>> our work is not completed if the called user does not know the =
result
>>> of the negotiation ( in most cases ). So for this example we have =
the
>>> preference indication we need, and we can say that the user needs to
>>> know the result but the mechanism for that is out of scope.
>>>>=20
>>>>> Even if you knew French and Italian, you would need to know that =
the
>>>>> common language is French.
>>>>>=20
>>>>> B.  One spoken and one written language
>>>>> I send an offer with spoken English in audio and written English =
in
>>>>> text. I call you, and you have also configured spoken English in
>>>>> audio and written English in text.
>>>>> We both prefer to talk if we have a chance.
>>>>> The negotiation succeeds and you get an indication that audio and
>>>>> text are the available media. If you do not get any preference
>>>>> indication, you do not know how to start the call. You may try
>>>>> English text fist and type "Hi, welcome, what can I do for you". I
>>>>> notice that you type, so I answer in text, because I do not know =
if
>>>>> you can talk English. We might continue the whole call in text, or
>>>>> take the effort to ask if we can change to talking.
>>>>> Not until you get to know that we both can use spoken English and
>>>>> that it is the preferred match, you get a chance to respond in
>>>>> spoken English and the call starts well. The device can convey the
>>>>> negotiation result to you without us specifyinng how, but we need =
to
>>>>> describe that my preference for spoken modality is conveyed by the
>>>>> protocol.
>>>> The protocol exchange informs BOTH ENDS that both voice and text is
>>>> negotiated.  It=92s perfectly fine for either end to start in =
either
>>>> modality, and switch any time they want to.
>>> No that is not perfectly fine. It is inconvenient and awkward to
>>> communicate in other than your favoured modality. And it is awkward =
to
>>> have a dialogue about what alternatives there are. A most simple
>>> mechanism to configure and convey the modality preference is needed =
as
>>> part of our protocol.
>>>=20
>>> You can have even more examples where the solution is to both have a
>>> favoured modality indication and a way (not specified by us) to =
convey
>>> the result of the negotiation to the users.
>>>=20
>>> Why shall we make a difference in conveying preference between
>>> languages in the same modality but not in different modalities? I do
>>> not see the logic in that.
>>>=20
>>> /Gunnar
>>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Many other examples can easily be constructed where we both need =
the
>>>>> preference between modalities and that the user get to know the
>>>>> result of the negotiation, or at least the best matching =
languages.
>>>>>=20
>>>>>> Please remember, we=92re not designing user interfaces, we=92re =
designing protocols.
>>>>> Yes, we specify the protocol for conveying information about
>>>>> language and modality between the sides involved in the call.
>>>>> In most cases some mechanism that we do not describe needs to take
>>>>> this information to the user so that the call can be completed
>>>>> successfully.
>>>>> The other way - that the user is expected to configure the =
languages
>>>>> and modalities is briefly mentioned in the introduction by these =
words:
>>>>>=20
>>>>> "Since this is a protocol mechanism, the user equipment (UE =
client)
>>>>>   needs to know the user's preferred languages; a reasonable =
technique
>>>>>   could include a configuration mechanism with a default of the =
language of the user interface.=94
>>>> That=92s in scope, because it=92s discussing configuration for the
>>>> protocol exchange.
>>> Well, let us add favoured modality and we are done.
>>>>> I suggest that we also say that "The result of the negotiation is =
expected to be provided to the user in most applications of this =
mechanism,
>>>>> but it is out of scope to specify how this is done.=94
>>>> That=92s out of scope, that=92s strictly user interface.
>>> Can you propose a rewording that it matches your view.
>>>>=20
>>>>> That would not be specifying user interface but clarifying the =
main purpose.
>>>>>=20
>>>>> The paragraph in the introduction continues:
>>>>>=20
>>>>>   "In some cases, a UE could tie
>>>>>   language and media preferences, such as a preference for a video
>>>>>   stream using a signed language and/or a text or audio stream =
using a
>>>>>   written/spoken language."
>>>>>=20
>>>>> I take this sentence as a promise that later in the document we =
will read how such preference between languages in different modalities
>>>>> is coded and conveyed between the UEs. Our work is not complete =
and does not do its job until we have specified a mechanism for that.
>>>> We can edit this text to remove the inference.
>>> We need instead sharpen it and then explain how.
>>>=20
>>> /Gunnar
>>>>=20
>>>>> It can be sufficient to add indication of the most preferred =
modality to the protocol, because within the modalities we have the =
order of the attributes as the preference order.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Gunnar
>>>>>=20
>>>>>> Brian
>>>>>>=20
>>>>>>=20
>>>>>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker =
> wrote:
>>>>>>>=20
>>>>>>> #8: Introduce a section on most favoured modality
>>>>>>>=20
>>>>>>>=20
>>>>>>> Comment (by gunnar.hellstrom@omnitor.se =
):
>>>>>>>=20
>>>>>>> This is not anymore a fully specified preference level between =
languages
>>>>>>> in different modalities. In this version it is just a single =
indication of
>>>>>>> the most favoured modality ( and by that the most favoured =
language).
>>>>>>>=20
>>>>>>> It is such a small addition, and so urgently needed to make the =
draft
>>>>>>> useful, that it should be allowed to be included.
>>>>>>>=20
>>>>>>> --
>>>>>>> =
-------------------------------------+------------------------------------=
-
>>>>>>> Reporter:                           |       Owner:  =
draft-ietf-slim-
>>>>>>> gunnar.hellstrom@omnitor.se        |  =
negotiating-human-language@ietf.org
>>>>>>>    Type:  enhancement              |      Status:  closed
>>>>>>> Priority:  major                    |   Milestone:
>>>>>>> Component:  negotiating-human-       |     Version:
>>>>>>> language                           |  Resolution:  wontfix
>>>>>>> Severity:  In WG Last Call          |
>>>>>>> Keywords:  modality                 |
>>>>>>> =
-------------------------------------+------------------------------------=
-
>>>>>>>=20
>>>>>>> Ticket URL: =

>>>>>>> slim 
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> SLIM mailing list
>>>>>>> SLIM@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>=20
>>>>> --
>>>>> -----------------------------------------
>>>>> Gunnar Hellstr=F6m
>>>>> Omnitor
>>>>> gunnar.hellstrom@omnitor.se
>>>>> +46 708 204 288
>>>>=20
>>>=20
>>> --
>>> -----------------------------------------
>>> Gunnar Hellstr=F6m
>>> Omnitor
>>> gunnar.hellstrom@omnitor.se
>>> +46 708 204 288
>>=20
>>=20
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim =

>>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org 
> https://www.ietf.org/mailman/listinfo/slim =


--Apple-Mail=_F87A5C0F-504D-48C8-B6B3-6C9A02CB7C83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Absolutely, that=92s one of my goals.  You indicate your =
preference for Spanish, and we route your call to a Spanish speaker. =
 We know we=92ve negotiated Spanish, so if the call taker is =
bilingual, the UI could show them what was negotiated. =
 Furthermore, if we need to send the call to an IVR, the IVR knows =
what was negotiated and thus plays the right prompts, which is an =
example where there is  no UI (on the call answering side).

Brian

On Aug 17, 2016, at 11:03 AM, Paul Kyzivat =
<pkyzivat@alum.mit.edu> wrote:

In general I think I agree with you. But I want =
to ensure we are getting to a place where we will be able to dispense =
with the "Press 1 if you speak Spanish".

When I call a call center I want to be directed =
automatically to someone who speaks my language and then be greeted in a =
language I speak.

	Thanks,
	Paul

On 8/17/16 10:25 AM, Brian Rosen =
wrote:
When you =
walk up to someone, and you both know more than one language,
how do you start?

We=92re =
actually very good at figuring out that kind of thing and we don=92t
need a lot of help to do it.

I=92m=
 not at all worried about humans figuring out what to do as long as
we get calls to people who actually can understand the =
languages the
caller prefers.

I=92m very, very suspicious of things that make assumptions =
about user
interface.  You are making lots of =
assumptions.  One of them is that
there is a human =
answering the call.  That is NOT something we should
assume.  Automatons behave differently than humans. =
 That=92s sometimes
bad, but it=92s sometimes =
good.

I=92m also against being a =
specification nanny.  Just as there are no
protocol =
police, there are no user interface police, and it may NOT be
the right thing to tell a user what the other guy=92s =
modality choice is.

Brian


On Aug =
17, 2016, at 10:13 AM, Gunnar Hellstr=F6m
<gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:



Den 2016-08-17 =
kl. 15:35, skrev Brian Rosen:

On Aug =
17, 2016, at 9:22 AM, Gunnar Hellstr=F6m
<gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>>
wrote:

Den 2016-08-16 kl. 23:50, =
skrev Brian Rosen:
I =
don=92t think this is useful, and I think it=92s beyond the consensus on =
what this document would contain.

If I send =
an offer of English audio and you can do it, then you will send an =
answer with English audio.  If you can=92t do it, then your answer =
won=92t include English audio.  Me telling you that English audio =
is most important doesn=92t change your answer.  This is especially =
true with modality.  There is no way I can use advice of which =
modality is most important to you.  If you offer video, I answer =
with some video if I can do video.  If I can=92t I won=92t include =
a video answer.  Telling me you realty, really want video isn=92t =
useful.
In some limited examples that would =
lead to successful call start.
But consider a couple of =
other simple cases:
A. Two common spoken languages:
I send an offer of spoken English and French in audio in =
both
directions, and you have configured your device that =
you also know
English and French in both directions.
Then, the protocol selects spoken English and puts that in =
the
answer. In order for the call to complete successfully =
you then need
to know that English both ways was selected, =
so that you start
talking English in your answer. It would =
be a failure of our
intentions if you only got a connected =
indication and needed to
start asking me what language I =
prefer.
We do not specify how the information is conveyed =
to you, but it is.
The protocol answer was =
English.  Both ends know that.  User
interface =
is out of scope.
Yes, user interface =
mechanisms are out of scope, but the intention of
our work =
is not completed if the called user does not know the result
of the negotiation ( in most cases ). So for this example we =
have the
preference indication we need, and we can say =
that the user needs to
know the result but the mechanism =
for that is out of scope.

Even if =
you knew French and Italian, you would need to know that the
common language is French.

B. =
 One spoken and one written language
I send an offer =
with spoken English in audio and written English in
text. =
I call you, and you have also configured spoken English in
audio and written English in text.
We both =
prefer to talk if we have a chance.
The negotiation =
succeeds and you get an indication that audio and
text are =
the available media. If you do not get any preference
indication, you do not know how to start the call. You may =
try
English text fist and type "Hi, welcome, what can I do =
for you". I
notice that you type, so I answer in text, =
because I do not know if
you can talk English. We might =
continue the whole call in text, or
take the effort to ask =
if we can change to talking.
Not until you get to know =
that we both can use spoken English and
that it is the =
preferred match, you get a chance to respond in
spoken =
English and the call starts well. The device can convey the
negotiation result to you without us specifyinng how, but we =
need to
describe that my preference for spoken modality is =
conveyed by the
protocol.
The =
protocol exchange informs BOTH ENDS that both voice and text is
negotiated.  It=92s perfectly fine for either end to =
start in either
modality, and switch any time they want =
to.
No that is not perfectly fine. It is =
inconvenient and awkward to
communicate in other than your =
favoured modality. And it is awkward to
have a dialogue =
about what alternatives there are. A most simple
mechanism =
to configure and convey the modality preference is needed as
part of our protocol.

You can =
have even more examples where the solution is to both have a
favoured modality indication and a way (not specified by us) =
to convey
the result of the negotiation to the users.

Why shall we make a difference in conveying =
preference between
languages in the same modality but not =
in different modalities? I do
not see the logic in =
that.

/Gunnar





Many other examples can easily be constructed where we both =
need the
preference between modalities and that the user =
get to know the
result of the negotiation, or at least the =
best matching languages.

Please remember, we=92re not designing user =
interfaces, we=92re designing protocols.
Yes, =
we specify the protocol for conveying information about
language and modality between the sides involved in the =
call.
In most cases some mechanism that we do not describe =
needs to take
this information to the user so that the =
call can be completed
successfully.
The =
other way - that the user is expected to configure the languages
and modalities is briefly mentioned in the introduction by =
these words:

"Since this is a protocol =
mechanism, the user equipment (UE client)
  needs =
to know the user's preferred languages; a reasonable technique
  could include a configuration mechanism with a =
default of the language of the user interface.=94
That=92s in scope, because it=92s discussing =
configuration for the
protocol exchange.
Well, let us add favoured modality and we are =
done.
I suggest that we also say that "The result of =
the negotiation is expected to be provided to the user in most =
applications of this mechanism,
but it is out of scope to =
specify how this is done.=94
That=92s out of =
scope, that=92s strictly user interface.
Can =
you propose a rewording that it matches your view.

That would not be specifying user interface =
but clarifying the main purpose.

The =
paragraph in the introduction continues:

  "In some cases, a UE could tie
  language and media preferences, such as a =
preference for a video
  stream using a signed =
language and/or a text or audio stream using a
  written/spoken language."

I take this sentence as a promise that later in the document =
we will read how such preference between languages in different =
modalities
is coded and conveyed between the UEs. Our work =
is not complete and does not do its job until we have specified a =
mechanism for that.
We can edit this text to =
remove the inference.
We need instead sharpen =
it and then explain how.

/Gunnar

It can be sufficient to add indication of the =
most preferred modality to the protocol, because within the modalities =
we have the order of the attributes as the preference order.



Gunnar

Brian


On Aug 16, 2016, at 5:36 PM, slim issue tracker <trac+slim@tools.ietf.org> wrote:

#8: Introduce a section on most favoured modality


Comment (by gunnar.hellstrom@omnitor.se):

This is not anymore a fully specified preference level =
between languages
in different modalities. In this version =
it is just a single indication of
the most favoured =
modality ( and by that the most favoured language).

It is such a small addition, and so urgently needed to make =
the draft
useful, that it should be allowed to be =
included.

--
-------------------------------------+-------------------------=
------------
Reporter: =
            &n=
bsp;           &nbs=
p; |       Owner: =
 draft-ietf-slim-
gunnar.hellstrom@omnitor.se =
       |  negotiating-human-language@ietf.org
   Type:  enhancement =
            &n=
bsp;|      Status:  closed
Priority:  major =
            &n=
bsp;      |   Milestone:
Component:  negotiating-human- =
      | =
    Version:
language =
            &n=
bsp;           &nbs=
p; |  Resolution:  wontfix
Severity: =
 In WG Last Call =
         |
Keywords:  modality =
            &n=
bsp;   |
-------------------------------------+-------------------------=
------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3=
>
slim <https://tools.ietf.org/slim/>

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

--
-----------------------------------------
Gunnar =
Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 =
288


--
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 =
288



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


_______________________________________________
SLIM mailing =
list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

=

--Apple-Mail=_F87A5C0F-504D-48C8-B6B3-6C9A02CB7C83--


From nobody Wed Aug 17 11:33:28 2016
Return-Path: 
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 1E80212D735; Wed, 17 Aug 2016 11:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 ZZKELJx5VYWP; Wed, 17 Aug 2016 11:33:24 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5BB12D670; Wed, 17 Aug 2016 11:33:24 -0700 (PDT)
Received: from localhost ([::1]:55421 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba5eU-00032o-Ty; Wed, 17 Aug 2016 11:33:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, doug@ewellic.org
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 18:33:22 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/14#comment:2
Message-ID: <071.bb4b363c89bf3817cfdb71d132b2669f@tools.ietf.org>
References: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org>
X-Trac-Ticket-ID: 14
In-Reply-To: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, doug@ewellic.org, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160817183324.BE5BB12D670@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 11:33:24 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #14 (negotiating-human-language): Expand acronyms
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 18:33:26 -0000

#14: Expand acronyms


Comment (by doug@ewellic.org):

 Sorry, I missed that ticket. I agree that removing the unexpanded acronyms
 in this paragraph, as suggested in #4, would resolve this issue.

 Any remaining acronyms that might not be obvious to all readers should be
 expanded on first reference in this document (not by reference to an
 external specification).

-- 
-------------------------------------+-------------------------------------
 Reporter:  doug@ewellic.org         |       Owner:  draft-ietf-slim-
     Type:  enhancement              |  negotiating-human-language@ietf.org
 Priority:  minor                    |      Status:  new
Component:  negotiating-human-       |   Milestone:
  language                           |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 11:54:44 2016
Return-Path: 
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 846B512B069 for ; Wed, 17 Aug 2016 11:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 ASzYpB_TtTMG for ; Wed, 17 Aug 2016 11:54:41 -0700 (PDT)
Received: from p3plwbeout03-02.prod.phx3.secureserver.net (p3plsmtp03-02-2.prod.phx3.secureserver.net [72.167.218.214]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A79127058 for ; Wed, 17 Aug 2016 11:54:40 -0700 (PDT)
Received: from localhost ([72.167.218.135]) by p3plwbeout03-02.prod.phx3.secureserver.net with bizsmtp id YJug1t0012vs63s01JugkG; Wed, 17 Aug 2016 11:54:40 -0700
X-SID: YJug1t0012vs63s01
Received: (qmail 3612 invoked by uid 99); 17 Aug 2016 18:54:40 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 208.51.143.189
User-Agent: Workspace Webmail 6.4.6
Message-Id: <20160817115439.665a7a7059d7ee80bb4d670165c8327d.3491f6646f.wbe@email03.godaddy.com>
From: "Doug Ewell" 
To: slim@ietf.org
Date: Wed, 17 Aug 2016 11:54:39 -0700
Mime-Version: 1.0
Archived-At: 
Subject: Re: [Slim] [slim] #14 (negotiating-human-language): Expand acronyms
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 18:54:42 -0000

Gunnar wrote a comment to ticket #14:=0A=0A> The same topic is dealt with i=
n issue #4. Possible references are=0A> provided in the discussion about is=
sue#4.=0A> References to SA1 and CR are not needed. There is a published 3G=
PP=0A> specification with the requirements.=0A=0AI agree, as long as any re=
maining non-obvious acronyms are expanded on=0Afirst reference, or in a glo=
ssary. The document should not send the=0Areader scurrying to an external s=
pecification or to Wikisomething to=0Afigure out what an acronym means.=0A=
=0A> The other acronyms could be included if it is decided that the=0A> ref=
erences are wanted. ( It is unusual for IETF to tell where IETF=0A> documen=
ts are used, and not needed for the specification of the=0A> mechanism)=0A=
=0AI don't understand this last sentence. When an RFC states informatively=
=0Athat the specification it describes may be useful in product or protocol=
=0AXYZ, it is common to include an informative reference to XYZ.=0A =0A--=
=0ADoug Ewell | Thornton, CO, US | ewellic.org


From nobody Wed Aug 17 12:13:40 2016
Return-Path: 
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 3E30F12D106 for ; Wed, 17 Aug 2016 12:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZNLM846DhVhk for ; Wed, 17 Aug 2016 12:13:34 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 46CBB12D0C5 for ; Wed, 17 Aug 2016 12:13:31 -0700 (PDT)
X-Halon-ID: ac097041-64ae-11e6-b846-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 17 Aug 2016 21:13:25 +0200 (CEST)
To: slim@ietf.org
References: <20160817115439.665a7a7059d7ee80bb4d670165c8327d.3491f6646f.wbe@email03.godaddy.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 17 Aug 2016 21:13:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160817115439.665a7a7059d7ee80bb4d670165c8327d.3491f6646f.wbe@email03.godaddy.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] [slim] #14 (negotiating-human-language): Expand acronyms
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 19:13:38 -0000

Den 2016-08-17 kl. 20:54, skrev Doug Ewell:
> Gunnar wrote a comment to ticket #14:
>
>> The same topic is dealt with in issue #4. Possible references are
>> provided in the discussion about issue#4.
>> References to SA1 and CR are not needed. There is a published 3GPP
>> specification with the requirements.
> I agree, as long as any remaining non-obvious acronyms are expanded on
> first reference, or in a glossary. The document should not send the
> reader scurrying to an external specification or to Wikisomething to
> figure out what an acronym means.
>
>> The other acronyms could be included if it is decided that the
>> references are wanted. ( It is unusual for IETF to tell where IETF
>> documents are used, and not needed for the specification of the
>> mechanism)
> I don't understand this last sentence. When an RFC states informatively
> that the specification it describes may be useful in product or protocol
> XYZ, it is common to include an informative reference to XYZ.
Yes, agreed, if the decision is to make an informative statement that 
the specification is useful for specifications of other organizations, 
then references to such documents should be included if available. ( and 
in this case they are  as shown in the discussion about Issue #4 ).



/Gunnar
>   
> --
> Doug Ewell | Thornton, CO, US | ewellic.org
>
> _______________________________________________
> 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


From nobody Wed Aug 17 15:17:35 2016
Return-Path: 
X-Original-To: slim@ietf.org
Delivered-To: slim@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31C12D0D9; Wed, 17 Aug 2016 15:17:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147147225425.23784.12060108895782701375.idtracker@ietfa.amsl.com>
Date: Wed, 17 Aug 2016 15:17:34 -0700
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-05.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:17:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : Multiple Language Content Type
        Authors         : Nik Tomkinson
                          Nathaniel Borenstein
	Filename        : draft-ietf-slim-multilangcontent-05.txt
	Pages           : 16
	Date            : 2016-08-17

Abstract:
   This document defines an addition to the Multipurpose Internet Mail
   Extensions (MIME) standard to make it possible to send one message
   that contains multiple language versions of the same information.
   The translations would be identified by a language tag and selected
   by the email client based on a user's language settings.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Aug 17 15:19:33 2016
Return-Path: 
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 BAAE412D7FD; Wed, 17 Aug 2016 15:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 XeTM2rbYnDUQ; Wed, 17 Aug 2016 15:19:20 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E13E12D529; Wed, 17 Aug 2016 15:19:18 -0700 (PDT)
Received: from localhost ([::1]:60424 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9B7-0003FP-K4; Wed, 17 Aug 2016 15:19:17 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:19:17 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/16#comment:1
Message-ID: <082.0709e770e4b6a30d4e2be5d8099eb71f@tools.ietf.org>
References: <067.17357bff46e93bc02517aa24fb7315c7@tools.ietf.org>
X-Trac-Ticket-ID: 16
In-Reply-To: <067.17357bff46e93bc02517aa24fb7315c7@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817221918.1E13E12D529@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 15:19:18 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #16 (multilangcontent): Reference message/global
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:19:32 -0000

#16: Reference message/global

Changes (by rfc.nik.tomkinson@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 15:19:45 2016
Return-Path: 
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 261EF12D7F6; Wed, 17 Aug 2016 15:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 RErC67oj2u3D; Wed, 17 Aug 2016 15:19:42 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD60512D67B; Wed, 17 Aug 2016 15:19:35 -0700 (PDT)
Received: from localhost ([::1]:60434 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9BP-0004bE-MN; Wed, 17 Aug 2016 15:19:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:19:35 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/17#comment:1
Message-ID: <082.a2a04f1d8b7060dda2253215e4c36861@tools.ietf.org>
References: <067.b7a881d4710a91cf786273b9b1c762ea@tools.ietf.org>
X-Trac-Ticket-ID: 17
In-Reply-To: <067.b7a881d4710a91cf786273b9b1c762ea@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817221935.BD60512D67B@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 15:19:35 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #17 (multilangcontent): Remove RFC 2119 keyword
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:19:43 -0000

#17: Remove RFC 2119 keyword

Changes (by rfc.nik.tomkinson@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 15:20:03 2016
Return-Path: 
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 41FE612D19F; Wed, 17 Aug 2016 15:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 hBwIe84rllSi; Wed, 17 Aug 2016 15:19:48 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946B012D0FB; Wed, 17 Aug 2016 15:19:47 -0700 (PDT)
Received: from localhost ([::1]:60441 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9Bb-0005Un-GN; Wed, 17 Aug 2016 15:19:47 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:19:47 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/18#comment:1
Message-ID: <082.02f3538d5a1b9591aecd56969d85009d@tools.ietf.org>
References: <067.bcd7dc3f784434c7cf7b620e40c89803@tools.ietf.org>
X-Trac-Ticket-ID: 18
In-Reply-To: <067.bcd7dc3f784434c7cf7b620e40c89803@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817221947.946B012D0FB@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 15:19:47 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #18 (multilangcontent): Email addresses in examples
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:19:58 -0000

#18: Email addresses in examples

Changes (by rfc.nik.tomkinson@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 15:20:38 2016
Return-Path: 
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 07A8412D19F for ; Wed, 17 Aug 2016 15:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 lgU9Sceti5Xj for ; Wed, 17 Aug 2016 15:20:35 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026E412D529 for ; Wed, 17 Aug 2016 15:20:32 -0700 (PDT)
Received: from localhost ([::1]:60474 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9CJ-0007uv-SS; Wed, 17 Aug 2016 15:20:31 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:20:31 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/19#comment:1
Message-ID: <082.e9d65d786cf737f49c7edf6fcab9ac9e@tools.ietf.org>
References: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-Trac-Ticket-ID: 19
In-Reply-To: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #19 (multilangcontent): Use Media Type registration template
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:20:37 -0000

#19: Use Media Type registration template

Changes (by rfc.nik.tomkinson@gmail.com):

 * owner:  draft-ietf-slim-multilangcontent@ietf.org =>
     rfc.nik.tomkinson@gmail.com
 * status:  new => assigned


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rfc.nik.tomkinson@gmail.com        |  rfc.nik.tomkinson@gmail.com
     Type:  enhancement              |      Status:  assigned
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 15:21:31 2016
Return-Path: 
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 9793A12D7E1 for ; Wed, 17 Aug 2016 15:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 VyvPM0i2CJl2 for ; Wed, 17 Aug 2016 15:21:28 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DE112D7EC for ; Wed, 17 Aug 2016 15:21:28 -0700 (PDT)
Received: from localhost ([::1]:60493 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9DE-0001Am-3v; Wed, 17 Aug 2016 15:21:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:21:28 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/19#comment:2
Message-ID: <082.1d3ce8ab8e2f8de5bd9a43f4ae2db94a@tools.ietf.org>
References: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-Trac-Ticket-ID: 19
In-Reply-To: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #19 (multilangcontent): Use Media Type registration template
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:21:29 -0000

#19: Use Media Type registration template


Comment (by rfc.nik.tomkinson@gmail.com):

 I am currently discussing the correct wording/structure for the
 registration template with Alexey.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rfc.nik.tomkinson@gmail.com        |  rfc.nik.tomkinson@gmail.com
     Type:  enhancement              |      Status:  assigned
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 15:21:53 2016
Return-Path: 
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 DBC8212D7F0; Wed, 17 Aug 2016 15:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 5oT-5ZK0UbZn; Wed, 17 Aug 2016 15:21:50 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B169912D7EE; Wed, 17 Aug 2016 15:21:50 -0700 (PDT)
Received: from localhost ([::1]:60503 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9Da-0002Wm-IP; Wed, 17 Aug 2016 15:21:50 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:21:50 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/20#comment:1
Message-ID: <082.793fe57e95b0a1072ba16ade1f3446a2@tools.ietf.org>
References: <067.f59ecbf0a7c40a473fcaa875edcbf471@tools.ietf.org>
X-Trac-Ticket-ID: 20
In-Reply-To: <067.f59ecbf0a7c40a473fcaa875edcbf471@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817222150.B169912D7EE@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 15:21:50 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #20 (multilangcontent): Update reference to I-D.gellens-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:21:52 -0000

#20: Update reference to I-D.gellens-slim-negotiating-human-language

Changes (by rfc.nik.tomkinson@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  rfc.nik.tomkinson@gmail.com        |  multilangcontent@ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 15:22:09 2016
Return-Path: 
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 054D412D18E; Wed, 17 Aug 2016 15:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 d88s9q_DgU5y; Wed, 17 Aug 2016 15:22:06 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE6D12D1E4; Wed, 17 Aug 2016 15:22:06 -0700 (PDT)
Received: from localhost ([::1]:60514 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba9Dq-0003JU-PB; Wed, 17 Aug 2016 15:22:06 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Wed, 17 Aug 2016 22:22:06 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/12#comment:1
Message-ID: <071.b52ddaf7b24201d1f69606a73c7d7ac1@tools.ietf.org>
References: <056.e854dcc7b4f5db3d3cbd8376701cd071@tools.ietf.org>
X-Trac-Ticket-ID: 12
In-Reply-To: <056.e854dcc7b4f5db3d3cbd8376701cd071@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-multilangcontent@ietf.org, rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-multilangcontent@ietf.org
Resent-Message-Id: <20160817222206.CFE6D12D1E4@ietfa.amsl.com>
Resent-Date: Wed, 17 Aug 2016 15:22:06 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #12 (multilangcontent): Consider removing health warning about short tags
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 22:22:08 -0000

#12: Consider removing health warning about short tags

Changes (by rfc.nik.tomkinson@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-slim-
  doug@ewellic.org       |  multilangcontent@ietf.org
     Type:  enhancement  |      Status:  closed
 Priority:  minor        |   Milestone:
Component:               |     Version:
  multilangcontent       |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
slim 


From nobody Wed Aug 17 21:28:45 2016
Return-Path: 
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 1957812D176; Wed, 17 Aug 2016 21:28:44 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 F3DuzlRVB2qk; Wed, 17 Aug 2016 21:28:43 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15312B00B; Wed, 17 Aug 2016 21:28:42 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 17 Aug 2016 21:28:42 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 17 Aug 2016 21:28:39 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Brian Rosen , slim issue tracker 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 04:28:44 -0000

At 3:22 PM +0200 8/17/16, Gunnar Hellstr=F6m wrote:

>   In order for the call to complete successfully=20
> you then need to know that English both ways=20
> was selected, so that you start talking English=20
> in your answer. It would be a failure of our=20
> intentions if you only got a connected=20
> indication and needed to start asking me what=20
> language I prefer.

Both endpoints know what was set up (English=20
audio in your example).  What the endpoints do=20
with this knowledge, including if and how they=20
communicate it to the user, is out of scope.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
How does a project get to be a year behind schedule?
One day at a time.   --Fred Brooks in _The Mythical Man Month_


From nobody Wed Aug 17 21:31:22 2016
Return-Path: 
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 446A312D176; Wed, 17 Aug 2016 21:31:21 -0700 (PDT)
X-Quarantine-ID: <4QZMvUXGPn7m>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 4QZMvUXGPn7m; Wed, 17 Aug 2016 21:31:19 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8A76312B00B; Wed, 17 Aug 2016 21:31:19 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 17 Aug 2016 21:31:19 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <30567D6E-B654-4B0C-A8CB-4E8F4B180CBC@brianrosen.net>
References: <067.033bb4c75a1be073bf1638fc7b12a580@tools.ietf.org> <30567D6E-B654-4B0C-A8CB-4E8F4B180CBC@brianrosen.net>
X-Mailer: Eudora for Mac OS X
Date: Wed, 17 Aug 2016 21:31:17 -0700
To: Brian Rosen , slim issue tracker 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #21 (negotiating-human-language): Add the text message modality to the realtime draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 04:31:21 -0000

This seems reasonable to me (adding brief mention of applicability to 
m=application and m=message).

--Randy

At 9:55 AM -0400 8/17/16, Brian Rosen wrote:

>  I support adding text, but it should be sufficient to mention that 
> the language tags can be applied to m=message sections.
>
>  I wouldn't want to assume anything about future modalities, but 
> maybe we could say something along the lines of "Application of the 
> humintlang tags to SDP sections where human understandable media in 
> specific languages is sent, such as m=application (e.g. WebRTC text 
> media) or m=message (MSRP) is permitted".  That might even cover 
> something like a screen share where you might have slides in 
> multiple media available.
>
>  I don't want to be very explicit, so we can cover new media streams 
> that have obvious meaning when we apply the tags without requiring 
> every new m= to have text saying how this spec applies.
>
>  Brian
>
>>  On Aug 17, 2016, at 9:42 AM, slim issue tracker 
>>  wrote:
>>
>>  #21: Add the text message modality to the realtime draft
>>
>>  There is a modality that we have not discussed at all yet. That is the
>>  "text message" modality. It is not really interactive, but very often used
>>  together with interactive media in a kind of slow pseudo-conversational
>>  mode. One implementation is MSRP that is specified by the m=message media.
>>  There seems to be some interest to extend our specification to handle that
>>  modality as well.
>>
>>  Then the text message modality needs to be described and how it is
>>  implicitly identified in sdp both in the main media m=message and in a
>>  subchannel of a data channel.
>>
>>  --
>>  -------------------------------------+-------------------------------------
>>  Reporter:                           |      Owner:  draft-ietf-slim-
>>   gunnar.hellstrom@omnitor.se        |  negotiating-human-language@ietf.org
>>      Type:  enhancement              |     Status:  new
>>  Priority:  major                    |  Milestone:
>>  Component:  negotiating-human-       |    Version:
>>   language                           |   Keywords:  message
>>  Severity:  In WG Last Call          |
>>  -------------------------------------+-------------------------------------
>>
>>  Ticket URL: 
>>  slim 
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Snacktrek, n.:
    The peculiar habit, when searching for a snack, of constantly
returning to the refrigerator in hopes that something new will have
materialized.                                --Rich Hall, "Sniglets"


From nobody Wed Aug 17 22:29:46 2016
Return-Path: 
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 2BF5F12D0BC for ; Wed, 17 Aug 2016 22:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IyulZDEqaFr1 for ; Wed, 17 Aug 2016 22:29:43 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D726312B015 for ; Wed, 17 Aug 2016 22:29:42 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id 74so13160945uau.0 for ; Wed, 17 Aug 2016 22:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=BCqzryRgsLOc/VUnEurWY5zD7AFBa+6LLRUwyXOVn6A=; b=tmTRXgSzODQrfDn2lGkEUiKwprOsIdRvYKv7Lg3RzSa4fdzvOY4wxg5fRWNk1Ydeh/ LQ4FcpUuelPrrdQeVVOlOlpgGx7cNUcsUhMLnV8HeBXHkezQCmaQSJI3ZwxOgsuA4TQQ IvRJ5gc8MNndGpMP2ycHvhvBBZgtf1EHRjRudZYqsvCSd8oDR/gFx0Wn2KMmPXh7leoI Z8YXpr7boCPmE5QqPGLAIIjk0dicBe8RV7RK6WJfkwSAXQivpgtEGXpg0NuWb9Zz+Tdp Kskdl/8L8ESj4/0+2UW+ggWEs+ol/4zCk05O5IIO54CXaEGZpKQdUglMkZwuVlIDMG64 KKHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=BCqzryRgsLOc/VUnEurWY5zD7AFBa+6LLRUwyXOVn6A=; b=a9SxhdzvjRoQ50fp4uhw+a89NNlh73BLb++QRuFaQY2s3ZLs3ejwLoqig1+mNwI0xZ GspVSpUgCda+tYUaNPOdvWKtgIq2c4wB57A5KhWKuiR8176dqRxfZz9Dtwz2q4Ynrtnr HKtVi8Z9x/c/6fkW0kmMSiizKhSFgwrbCf1pe40o6NRO0Qqx6SX0ofez1BZ/zrfOUWgJ ucvQqtN3PgOvlMrDnyprzJz8wdTWoevgbWx9e2WkYEbt18upKobqI2JCipaPQZ2OxWWF xO7s6zFks49CQSdMI2de3DtSb7AMFAodkD7SUcHwylrJ3KnQ0g/p42dQ27VNu7byMqD8 7DPw==
X-Gm-Message-State: AEkoouuMloPSqAZc1UmfUjRE62n4Bq4zrKQVXNG03sS55c93oYXKe8gINWROGQ9CMi94tOFkru338r53/x6l6g==
X-Received: by 10.176.65.40 with SMTP id j37mr141929uad.116.1471498181961; Wed, 17 Aug 2016 22:29:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.82.184 with HTTP; Wed, 17 Aug 2016 22:29:41 -0700 (PDT)
Received: by 10.176.82.184 with HTTP; Wed, 17 Aug 2016 22:29:41 -0700 (PDT)
In-Reply-To: <30567D6E-B654-4B0C-A8CB-4E8F4B180CBC@brianrosen.net>
References: <067.033bb4c75a1be073bf1638fc7b12a580@tools.ietf.org> <30567D6E-B654-4B0C-A8CB-4E8F4B180CBC@brianrosen.net>
From: Bernard Aboba 
Date: Wed, 17 Aug 2016 22:29:41 -0700
Message-ID: 
To: Brian Rosen , slim@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c122a9a6c6f6b053a51deeb
Archived-At: 
Subject: Re: [Slim] [slim] #21 (negotiating-human-language): Add the text message modality to the realtime draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 05:29:45 -0000

--94eb2c122a9a6c6f6b053a51deeb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Addition of some text on screen sharing seems like a good idea. There are
differences between screen sharing/remote control implemented with
m=3Dapplication (e.g. RDP screen sharing) and WebRTC screen sharing, which =
is
handled with m=3Dvideo.

In WebRTC scree sharing, an offer might include one m=3Dvideo line with
a=3Dsendonly advertising the ability to send English (the screen share) and
another m=3Dvideo line with a=3Dsendrecv (generated by a webcam), advertisi=
ng
the ability to send and receive ASL. It may not be obvious from the SDP
that one of the m=3Dvideo lines is a screen share and even if the  O/A
exchange accepts the screen sharing m line (without both sides even knowing
what it is for), it might or might not be used.

On Aug 17, 2016 6:55 AM, "Brian Rosen"  wrote:

> I support adding text, but it should be sufficient to mention that the
> language tags can be applied to m=3Dmessage sections.
>
> I wouldn=E2=80=99t want to assume anything about future modalities, but m=
aybe we
> could say something along the lines of =E2=80=9CApplication of the humint=
lang tags
> to SDP sections where human understandable media in specific languages is
> sent, such as m=3Dapplication (e.g. WebRTC text media) or m=3Dmessage (MS=
RP) is
> permitted=E2=80=9D.  That might even cover something like a screen share =
where you
> might have slides in multiple media available.
>
> I don=E2=80=99t want to be very explicit, so we can cover new media strea=
ms that
> have obvious meaning when we apply the tags without requiring every new m=
=3D
> to have text saying how this spec applies.
>
> Brian
>
> > On Aug 17, 2016, at 9:42 AM, slim issue tracker <
> trac+slim@tools.ietf.org> wrote:
> >
> > #21: Add the text message modality to the realtime draft
> >
> > There is a modality that we have not discussed at all yet. That is the
> > "text message" modality. It is not really interactive, but very often
> used
> > together with interactive media in a kind of slow pseudo-conversational
> > mode. One implementation is MSRP that is specified by the m=3Dmessage
> media.
> > There seems to be some interest to extend our specification to handle
> that
> > modality as well.
> >
> > Then the text message modality needs to be described and how it is
> > implicitly identified in sdp both in the main media m=3Dmessage and in =
a
> > subchannel of a data channel.
> >
> > --
> > -------------------------------------+----------------------
> ---------------
> > Reporter:                           |      Owner:  draft-ietf-slim-
> >  gunnar.hellstrom@omnitor.se        |  negotiating-human-language@
> ietf.org
> >     Type:  enhancement              |     Status:  new
> > Priority:  major                    |  Milestone:
> > Component:  negotiating-human-       |    Version:
> >  language                           |   Keywords:  message
> > Severity:  In WG Last Call          |
> > -------------------------------------+----------------------
> ---------------
> >
> > Ticket URL: 
> > slim 
> >
> > _______________________________________________
> > SLIM mailing list
> > SLIM@ietf.org
> > https://www.ietf.org/mailman/listinfo/slim
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

--94eb2c122a9a6c6f6b053a51deeb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Addition of some text on screen sharing seems like a good id=
ea. There are differences between screen sharing/remote control implemented=
 with m=3Dapplication (e.g. RDP screen sharing) and WebRTC screen sharing, =
which is handled with m=3Dvideo.


 In WebRTC scree sharing, an offer might include one m=3Dvid=
eo line with a=3Dsendonly advertising the ability to send English (the scre=
en share) and another m=3Dvideo line with a=3Dsendrecv (generated by a webc=
am), advertising the ability to send and receive ASL. It may not be obvious=
 from the SDP that one of the m=3Dvideo lines is a screen share and even if=
 the=C2=A0 O/A exchange accepts the screen sharing m line (without both sid=
es even knowing what it is for), it might or might not be used. 



On Aug 17, 2016 6=
:55 AM, "Brian Rosen" <br=
@brianrosen.net> wrote:
I support adding text, but it should be sufficient to mention th=
at the language tags can be applied to m=3Dmessage sections.



I wouldn=E2=80=99t want to assume anything about future modalities, but may=
be we could say something along the lines of =E2=80=9CApplication of the hu=
mintlang tags to SDP sections where human understandable media in specific =
languages is sent, such as m=3Dapplication (e.g. WebRTC text media) or m=3D=
message (MSRP) is permitted=E2=80=9D.=C2=A0 That might even cover something=
 like a screen share where you might have slides in multiple media availabl=
e.



I don=E2=80=99t want to be very explicit, so we can cover new media streams=
 that have obvious meaning when we apply the tags without requiring every n=
ew m=3D to have text saying how this spec applies.



Brian



> On Aug 17, 2016, at 9:42 AM, slim issue tracker <trac+slim@tools.ietf.org> wrote:

>

> #21: Add the text message modality to the realtime draft

>

> There is a modality that we have not discussed at all yet. That is the=


> "text message" modality. It is not really interactive, but v=
ery often used

> together with interactive media in a kind of slow pseudo-conversationa=
l

> mode. One implementation is MSRP that is specified by the m=3Dmessage =
media.

> There seems to be some interest to extend our specification to handle =
that

> modality as well.

>

> Then the text message modality needs to be described and how it is

> implicitly identified in sdp both in the main media m=3Dmessage and in=
 a

> subchannel of a data channel.

>

> --

> -------------------------------------+----------------------=
---------------

> Reporter:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 Owner:=C2=A0 dr=
aft-ietf-slim-

>=C2=A0 gunnar.hellstrom@=
omnitor.se=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 negotiating-human-language@ietf.org<=
br>
>=C2=A0 =C2=A0 =C2=A0Type:=C2=A0 enhancement=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0Status:=C2=A0 new

> Priority:=C2=A0 major=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 Milestone:

> Component:=C2=A0 negotiating-human-=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 Version:

>=C2=A0 language=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Keywords:=C2=A0 mess=
age

> Severity:=C2=A0 In WG Last Call=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> -------------------------------------+----------------------=
---------------

>

> Ticket URL: <https://trac.tools.ietf.org/<=
wbr>wg/slim/trac/ticket/21>

> slim <https://tools.ietf.org/slim/>

>

> _______________________________________________

> SLIM mailing list

> SLIM@ietf.org

> https://www.ietf.org/mailman/listinfo/slim


_______________________________________________

SLIM mailing list

SLIM@ietf.org

https://www.ietf.org/mailman/listinfo/slim




--94eb2c122a9a6c6f6b053a51deeb--


From nobody Wed Aug 17 23:26:58 2016
Return-Path: 
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 3DC0E12D661 for ; Wed, 17 Aug 2016 23:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 8zs9_m1UleK9 for ; Wed, 17 Aug 2016 23:26:55 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 DF12D126579 for ; Wed, 17 Aug 2016 23:26:54 -0700 (PDT)
X-Halon-ID: c0bac5a2-650c-11e6-be68-005056913f0f
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 18 Aug 2016 08:26:52 +0200 (CEST)
To: Randall Gellens , Brian Rosen , slim issue tracker 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>
Date: Thu, 18 Aug 2016 08:26:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org, Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 06:26:57 -0000

Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
> At 3:22 PM +0200 8/17/16, Gunnar Hellström wrote:
>
>>   In order for the call to complete successfully you then need to 
>> know that English both ways was selected, so that you start talking 
>> English in your answer. It would be a failure of our intentions if 
>> you only got a connected indication and needed to start asking me 
>> what language I prefer.
>
> Both endpoints know what was set up (English audio in your example).  
> What the endpoints do with this knowledge, including if and how they 
> communicate it to the user, is out of scope.
>
Yes, agreed. So our task in this draft is to describe the mechanism that 
enable the endpoints to have the information needed for a successful and 
smooth start of the call = greeting from the called party in the most 
appropriate language and modality.


Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


From nobody Thu Aug 18 02:30:45 2016
Return-Path: 
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 03C6712D09B for ; Thu, 18 Aug 2016 02:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 fhZTWCpW7ryu for ; Thu, 18 Aug 2016 02:30:40 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 5BD2B12B017 for ; Thu, 18 Aug 2016 02:30:40 -0700 (PDT)
X-Halon-ID: 683a9524-6526-11e6-b30f-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 18 Aug 2016 11:30:31 +0200 (CEST)
To: slim@ietf.org
References: <067.033bb4c75a1be073bf1638fc7b12a580@tools.ietf.org> <30567D6E-B654-4B0C-A8CB-4E8F4B180CBC@brianrosen.net> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <204f0317-b1c6-438d-b5fd-8378b1d2c8ee@omnitor.se>
Date: Thu, 18 Aug 2016 11:30:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------EF84ABB79C4A9A60115B1DC4"
Archived-At: 
Subject: Re: [Slim] [slim] #21 (negotiating-human-language): Add the text message modality to the realtime draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 09:30:44 -0000

This is a multi-part message in MIME format.
--------------EF84ABB79C4A9A60115B1DC4
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Den 2016-08-18 kl. 07:29, skrev Bernard Aboba:
>
> Addition of some text on screen sharing seems like a good idea. There 
> are differences between screen sharing/remote control implemented with 
> m=application (e.g. RDP screen sharing) and WebRTC screen sharing, 
> which is handled with m=video.
>
> In WebRTC scree sharing, an offer might include one m=video line with 
> a=sendonly advertising the ability to send English (the screen share) 
> and another m=video line with a=sendrecv (generated by a webcam), 
> advertising the ability to send and receive ASL. It may not be obvious 
> from the SDP that one of the m=video lines is a screen share and even 
> if the  O/A exchange accepts the screen sharing m line (without both 
> sides even knowing what it is for), it might or might not be used.
>
It seems to me that you should register and use a value for RFC 4796, 
the sdp Content Attribute for shared screen.
The task for the humintlang attributes is to be a tool for negotiating 
the main conversational languages and modalities. So, if you do not have 
the intention to use the shared screen for the main dialogue it should 
not have the humintlang attribute.

This could be an application where you use the lang attribute for the 
shared screen, if you just want to describe what languages are available 
on that shared screen. But the current RFC 4566 information on the Lang 
attribute also talks about default language for the session, so we 
should spend some efforts on describing in the humintlang draft how an 
sdp with mixed lang and humintlang attributes shall be interpreted.

I can imagine applications where a shared screen can be used for the 
main dialogue. It could be for communication with persons with cognitive 
disabilities, when you exchange semi-stndardised pictograms. There are 
apps for that purpose, but a shared screen could be a rapid way to get 
some communication going when a need suddenly appears. But I think it 
takes us too far if we include that in the humintlang draft now.

/Gunnar
>
> On Aug 17, 2016 6:55 AM, "Brian Rosen"  > wrote:
>
>     I support adding text, but it should be sufficient to mention that
>     the language tags can be applied to m=message sections.
>
>     I wouldn’t want to assume anything about future modalities, but
>     maybe we could say something along the lines of “Application of
>     the humintlang tags to SDP sections where human understandable
>     media in specific languages is sent, such as m=application (e.g.
>     WebRTC text media) or m=message (MSRP) is permitted”.  That might
>     even cover something like a screen share where you might have
>     slides in multiple media available.
>
>     I don’t want to be very explicit, so we can cover new media
>     streams that have obvious meaning when we apply the tags without
>     requiring every new m= to have text saying how this spec applies.
>
>     Brian
>
>     > On Aug 17, 2016, at 9:42 AM, slim issue tracker
>     > wrote:
>     >
>     > #21: Add the text message modality to the realtime draft
>     >
>     > There is a modality that we have not discussed at all yet. That
>     is the
>     > "text message" modality. It is not really interactive, but very
>     often used
>     > together with interactive media in a kind of slow
>     pseudo-conversational
>     > mode. One implementation is MSRP that is specified by the
>     m=message media.
>     > There seems to be some interest to extend our specification to
>     handle that
>     > modality as well.
>     >
>     > Then the text message modality needs to be described and how it is
>     > implicitly identified in sdp both in the main media m=message
>     and in a
>     > subchannel of a data channel.
>     >
>     > --
>     >
>     -------------------------------------+-------------------------------------
>     > Reporter:                           |      Owner: draft-ietf-slim-
>     > gunnar.hellstrom@omnitor.se 
>           | negotiating-human-language@ietf.org
>     
>     >     Type:  enhancement              |     Status:  new
>     > Priority:  major                    |  Milestone:
>     > Component:  negotiating-human-       |    Version:
>     >  language                           |   Keywords: message
>     > Severity:  In WG Last Call          |
>     >
>     -------------------------------------+-------------------------------------
>     >
>     > Ticket URL:      >
>     > slim 
>     >
>     > _______________________________________________
>     > SLIM mailing list
>     > SLIM@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/slim
>     
>
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>     
>
>
>
> _______________________________________________
> 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


--------------EF84ABB79C4A9A60115B1DC4
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2016-08-18 kl. 07:29, skrev Bernard Aboba:

    

      
Addition of some text on screen sharing seems like a
        good idea. There are differences between screen sharing/remote
        control implemented with m=application (e.g. RDP screen sharing)
        and WebRTC screen sharing, which is handled with m=video.

      
 In WebRTC scree sharing, an offer might include one
        m=video line with a=sendonly advertising the ability to send
        English (the screen share) and another m=video line with
        a=sendrecv (generated by a webcam), advertising the ability to
        send and receive ASL. It may not be obvious from the SDP that
        one of the m=video lines is a screen share and even if the  O/A
        exchange accepts the screen sharing m line (without both sides
        even knowing what it is for), it might or might not be used. 

    

    It seems to me that you should register and use a value for RFC
    4796, the sdp Content Attribute for shared screen.

    The task for the humintlang attributes is to be a tool for
    negotiating the main conversational languages and modalities. So, if
    you do not have the intention to use the shared screen for the main
    dialogue it should not have the humintlang attribute. 

    

    This could be an application where you use the lang attribute for
    the shared screen, if you just want to describe what languages are
    available on that shared screen. But the current RFC 4566
    information on the Lang attribute also talks about default language
    for the session, so we should spend some efforts on describing in
    the humintlang draft how an sdp with mixed lang and humintlang
    attributes shall be interpreted. 

    

    I can imagine applications where a shared screen can be used for the
    main dialogue. It could be for communication with persons with
    cognitive disabilities, when you exchange semi-stndardised
    pictograms. There are apps for that purpose, but a shared screen
    could be a rapid way to get some communication going when a need
    suddenly appears. But I think it takes us too far if we include that
    in the humintlang draft now. 

    

    /Gunnar

    

      


        
On Aug 17, 2016 6:55 AM, "Brian Rosen"
          <br@brianrosen.net>
          wrote:

          
I support
            adding text, but it should be sufficient to mention that the
            language tags can be applied to m=message sections.

            

            I wouldn’t want to assume anything about future modalities,
            but maybe we could say something along the lines of
            “Application of the humintlang tags to SDP sections where
            human understandable media in specific languages is sent,
            such as m=application (e.g. WebRTC text media) or m=message
            (MSRP) is permitted”.  That might even cover something like
            a screen share where you might have slides in multiple media
            available.

            

            I don’t want to be very explicit, so we can cover new media
            streams that have obvious meaning when we apply the tags
            without requiring every new m= to have text saying how this
            spec applies.

            

            Brian

            

            > On Aug 17, 2016, at 9:42 AM, slim issue tracker <trac+slim@tools.ietf.org>
            wrote:

            >

            > #21: Add the text message modality to the realtime
            draft

            >

            > There is a modality that we have not discussed at all
            yet. That is the

            > "text message" modality. It is not really interactive,
            but very often used

            > together with interactive media in a kind of slow
            pseudo-conversational

            > mode. One implementation is MSRP that is specified by
            the m=message media.

            > There seems to be some interest to extend our
            specification to handle that

            > modality as well.

            >

            > Then the text message modality needs to be described
            and how it is

            > implicitly identified in sdp both in the main media
            m=message and in a

            > subchannel of a data channel.

            >

            > --

            > -------------------------------------+-------------------------------------

            > Reporter:                           |      Owner: 
            draft-ietf-slim-

            >  gunnar.hellstrom@omnitor.se 
                  |  negotiating-human-language@ietf.org

            >     Type:  enhancement              |     Status:  new

            > Priority:  major                    |  Milestone:

            > Component:  negotiating-human-       |    Version:

            >  language                           |   Keywords: 
            message

            > Severity:  In WG Last Call          |

            > -------------------------------------+-------------------------------------

            >

            > Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/21>

            > slim <https://tools.ietf.org/slim/>

            >

            > _______________________________________________

            > SLIM mailing list

            > SLIM@ietf.org

            > https://www.ietf.org/mailman/listinfo/slim

            

            _______________________________________________

            SLIM mailing list

            SLIM@ietf.org

            https://www.ietf.org/mailman/listinfo/slim

          

        

      

      

      

      

      
_______________________________________________
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

  


--------------EF84ABB79C4A9A60115B1DC4--


From nobody Thu Aug 18 04:45:35 2016
Return-Path: 
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 7030F12D999; Thu, 18 Aug 2016 04:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
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 ttjeJjRBcots; Thu, 18 Aug 2016 04:45:31 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0137.outbound.protection.outlook.com [104.47.93.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B11512D99D; Thu, 18 Aug 2016 04:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=onNxZdIlt+HZ2ZA3XBsyPtKZx1/81KuRvrtxIbnPYQk=; b=ceGPErhUsec3clj0PBv3IgWkd3Xnsf8yySCRKZ9IvQNtQvZccwHT+SS0Pk7e8STPak0oYn3miE/I+bCbhzQrdjqrE5WJ6y2ygOyM99XmCKRIIJOjcNQcc2bE+GuboZ/0TM6Z2GRrzUzAfE4QQjKm4AsQMh5AxbG1a4Hce3lM3/c=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; 
Received: from [10.184.39.34] (213.55.184.249) by TYXPR01MB0928.jpnprd01.prod.outlook.com (10.168.45.23) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15; Thu, 18 Aug 2016 11:45:22 +0000
To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , Brian Rosen 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net> <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se>
From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <55485a96-a691-534c-767c-cedf1660ad7c@it.aoyama.ac.jp>
Date: Thu, 18 Aug 2016 20:45:00 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [213.55.184.249]
X-ClientProxiedBy: HE1PR0701CA0029.eurprd07.prod.outlook.com (10.165.214.167) To TYXPR01MB0928.jpnprd01.prod.outlook.com (10.168.45.23)
X-MS-Office365-Filtering-Correlation-Id: 6d183436-1584-46b6-ec71-08d3c75d24f4
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 2:mtCLVdQrKSo+OGYWVJJdlz6AOUnnWXAQPfIG8ZzzEXSbzoJe0kVbBg+FfMu4wwT/9YiTxYGwn+/G16KirnTKfMxzlOvo5HScE1fzZfavS0MK5jkWzHpKA80FNemqag2GNlQSNReF4b6bw9XvCKFDAkZV5EStGT0uJVFTsFMYxlFm6I5b4EVk3MxhMIvz4uWk; 3:1sOmfVZzJLVSCefZ/U9rRBUqrsKBAa+jhf/pUP7EcPUdgyJenz2FfM2LlExF1AcbI6iDiQEzCZqvbvFhwhFeKphHUNvW5MZ+oVVE+qyqqJnAfAjjdSQ4bKYc8+H7Cc3D
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0928;
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 25:IIdT9nWYHHylorMAvgVRgBoppO9nEdLnmT3/w+zppywlM4VMdN5uFDRguXhfIgfUt7ZfSc09sU3K6SMzpO1YVM6Jgtugar/e9inbOpl0WVfcNCqZH85f/S8qnDqc6cxK4pDPlgrWBWjRe/syIQkXQyLy06QVyKcJfWKJkh9KpOGAeml/s3dtT4c0mlZpz7EIPCgFcQFFoDWGDS9E9G59OelIifwSKFKIBREFDiVqvILsp22SWomWZP7HuPUp1NB/dr4izMchNbLQ/Wjow9no66Qd+ODzsBQYZrXhxDEi6uEoKSmK+2Ui43N3K10wd/M6oAz0uUT/gOweytw57dBapMV964Nol8EYiusPK28fid8M2Oj8i5OrteqZQLED3deePYFLe3L95OJ6A7yccQgys/nmDnAOnkuRDbzy7xx/iT15WALbekH6tfeX84u5Oo7rbhzUDboQbapClwo7ioHyGNPZkwx2j15m3aAQkVL7k6KoPPAR0YZWb3xGmfSNHVxN2fohZO7QwY9HWsLv3a1X4KiA2wcMti1zt7WGKrhQ/jDCNA6q3FlGVT8VfmmaDNfTQa0MCePTFitx/h1Njs/Jyc3u9VuvwKoXvV0YtA6WAa3Wl/O/5SdAZwK57s46ubc4r5qB8a827D0IdGLOf5B8RjAIyzlQew6OCFNHm3Zd1UjIwiXcEMSKCXOWd7v2LpfywF6Lp1XpWk50SAMbGmhpuUlJbXoWGrSNkbPxoKX8aEU=
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 31:OcfY5slPUQ0nEDiKC1TXe0RiKA+JAWZKECjEAJlR0ChiSE3UPhGHwUXddo/1qGqPJ/hqmJWmMnQw+j3jEzyF/A0ec25NZrrskvlixvlGcQ0iSJLDnM9jlUnHm5V4sLK1iJmZOja9wSqNGJ1WAkb3n+0fKc5Y6YLpiSPVOv7hTYWiBgs5vJ6pfo2XK2eEgjdM4wpH5ssjiyVwkjp8X7Si9HnaepAb/3674H/rzd374SM=; 4:IGaGhgW7XInF+d2yYC8C4bPUi3nMpCLFZgbwCUw1GNCXinQTtY6y0B86VQH/zejpqVe78evYMj3YOTuPc4LE737pysZE88cgRxWn3QnpiaYHoLFX+w0eeEJWfOh9h58EDr7UB0oWG0LeKOyu04NRCj6vq0T4YUOTDwfJFT69azjrKSBJ3RPTzO0q/9hh2AAmQ9ukqpOLhJRLXnnfnva7UQgYIvaIXEeX7jRCOZ3ncQPpDqPT84HCwyScXE730sXITzdNT3tQy5bnVW1j/2qgiWcQgI7A315mBULXOHLdaza3RyizMFw5T7fjcnTtCW1ig1+mb8orbF00Y3942E3/qAG+7RTidXPFfdc5wJjcJu+jJPXWml7wiK3PPTicIEJxI+GqiT7NGwed5QJgTyt4Tzuc9/TWO3tiQd6AiB3mSag=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:TYXPR01MB0928; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0928; 
X-Forefront-PRVS: 0038DE95A2
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(199003)(377424004)(24454002)(189002)(230783001)(65956001)(65806001)(66066001)(31696002)(2870700001)(42186005)(105586002)(31686004)(586003)(50466002)(8676002)(47776003)(81156014)(81166006)(86362001)(2950100001)(77096005)(4001350100001)(97736004)(5001770100001)(101416001)(54356999)(3846002)(76176999)(6116002)(50986999)(68736007)(2906002)(4326007)(64126003)(74482002)(189998001)(19580395003)(92566002)(19580405001)(8666005)(83506001)(7846002)(305945005)(7736002)(33646002)(23676002)(93886004)(106356001)(7099028)(65826006)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0928; H:[10.184.39.34]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI4OzIzOjBSSjUxRitvNmFlQVpnclVwTDE4SjRxZ0Yy?= =?utf-8?B?MjROZmxsRVlJMGk4R2czMHpHWUF6dTVBOHl6dXJtekJBYTB3TDkzQ0lnQTlS?= =?utf-8?B?Mldpd2R5UDNScEF5aGNrVWh6RTdHZEU0RVg2eCsxbllnUHg5TXA5RnpCbWh3?= =?utf-8?B?Mkczb2RFNEo2QmJOdUFwY0h0MDAyNHRtbDZLR3p1bzJmNjZxQUgrMzV4OGJW?= =?utf-8?B?UDFRRVNJdmJiUk9ZWTRWbXlKekkzN1NxdmlmSTV4WDF2SjVsaVArZ1lGZzZr?= =?utf-8?B?b09CcTN2WXg3K0c3UzlMVVJuWVBiWVVxcjNMTkZXMFR1a0xKTUpqUjNZZjhY?= =?utf-8?B?TnhyRXRFZGFPbTYwT2NMdUgwbXA3Z1QxeFFSSTJIUkk4dTE4ZzRDdWNrOENP?= =?utf-8?B?MGxDWkRqTzc3U2wzTkZFSnp0TXg1Z0kzZVBMVVdKUWFjV3pCRlptZlZKa0g4?= =?utf-8?B?azV5MUtpZERFVjFYV3FFb2dydHRCQitjdDd1QmRXSHhCYWhxcnJOaEZCR09L?= =?utf-8?B?VXoxOUJEM3FVZlVCc3J0K0JuYXRFcGp6aWFIalNsWGN3ZktIZXVCcCtjMWlM?= =?utf-8?B?T3o0NHlNWFN1cVlQaDh4NVB3NTVraUhNS3JjUjdJckZTK3JSZ3RRNytsWGND?= =?utf-8?B?RGZsaTcxbVQyZzcvVm9lRHZ1OVFCRG4wcGpmSjRDaEsvNzFabTRONGRqd1hW?= =?utf-8?B?VlY0TkZaa21NSElCRHBuOWdER1hJdmMraXdUVllDakYrYTJrUkF0VlZaUTlL?= =?utf-8?B?bVAzMHVNRXp2MGFKdWJIZVpPdnBwR2w4bGpiMXhvcklqVjVIN1RjYUd1eElh?= =?utf-8?B?MUYzcmozak04S2pSNGc0RzV5WGdHb3BpbmV4TjRkV1Yvc0l1Tm1jY3AybUpH?= =?utf-8?B?MWFtNDBMVG1OcGNUL3p2aTVRT1l1UmhNMkZwQ1FIY3IyK1VmV3FDNVMzQ3VR?= =?utf-8?B?N1VaL21pR01kZUFmakdhNWtVM2hPRTU0SGZobndHbHV1L29WdW1ncEk1Kzc0?= =?utf-8?B?djRZSFVFZitWRHdjVXdqZjlpaEFOeS9SRWdzdkhHeGxoRFB0VnE5TUVlUTBh?= =?utf-8?B?ZnZsbHZMczBjbVlvNWlsaFBwQjhLTkRkcXVRemcwSzBSa05nb0xaRTljWnpu?= =?utf-8?B?cG03d1pOM3VhekJPOGtZNVdONGlzNHk3cklMSFJhZ2J3dCs1cVVBS3Z4U1F4?= =?utf-8?B?YkFsOTNnTktRdExJdWFOcms1U2RJM09ZUWhUOGFNZC91Q0lNM25GS2JBMUhT?= =?utf-8?B?YXljNXRSNW05MzlXVko4NFVoUVRyR2sxcnBJYjJwOW5YaUpQMVUva3JlaGZG?= =?utf-8?B?Q1dzSWFRQVJLbld2R0NIM0lIeDFTSTBHR1k5NTJ2YnM0YjNxbDQwSGlybFRy?= =?utf-8?B?aXVwaVBOUk5JRmRDMHNMUWNzLzlXTFpJWlcwVlRKNGc0VWdHRDU0T2JFS0Zz?= =?utf-8?B?ZmRsR1hkYzdCa0NPczQ2TDJDQjRFOU5sbDZ5dmZwNWlDNW9CSDVTWC80NC8x?= =?utf-8?B?WEFqbVNQZm9xTUJydU5HcTRaYlo4Ym9yMTJhK3hkMlFBdFdITVdXRUhLdlc0?= =?utf-8?B?MFNxYTJjMlF5dC9VTzhuNXFhR0YzYnd3eEkvdDBveTdTdzR5bWdtRmROOXZy?= =?utf-8?B?TStlVlRaY3ZEZGZ6MkdWV0d6dkk3bDRteGV5bnhDUkFYUUdYeWdEZlQzcDhw?= =?utf-8?B?Qkd3UUpaa3V3Mk5ZTXdhMGp2bkYzY25HcUlCTmZGYmlKTmJ4dWNZQXB4SjI0?= =?utf-8?B?SjdkNUVTMERRU01lTWxMVE1wY3ZRYTdCTFNYSkNEVmlLeDlKYlUvdWl2RG14?= =?utf-8?B?Z3dDL2RWazR6RVhHVFBBVWxYbm51dmI2MWNwMHJ3RXova09SeVN4R1Q0Q001?= =?utf-8?Q?x+pc2YnVas8SMD9X//X/TNpMmYLhn4aF?=
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 6:h95f7MLlPrMrNr+WwRgJdwIbjx0gdjgu5X2ROKtGsfufcchLW5jto9Gmd7K2FRfkqf5LMbsHJ6RmgF+KWVGL+WCZniRBfEqkhJO5I0X38I5YPwnkwyJfd6MM8yvOpSGIbYwZCMLdd0BX7z6/sS0kUHljAfnqTSYyHb5tjbFIvPg3l045jE5oKy4AKxJ1y2LL2iknJZzvcuORCqR4g4uaTkWx47hcrvwujIBR39PEWWq0deIOqR3PM/M8WiZ1hnVM1qcMJbzKjH8vWEgaKRWA+YGKQ/jgoHeXfHE9JhPu9L3Jh4uceTqFCKRttakQq2BU; 5:AKrA1XoLOfIWSUCGcqcd8UbK5Yauc2gQYfSVoi0oarKFXTRNt+i74x1QOHnaLUb4WZ+6NiLkBV11TI1qYT4LvBjp8ZlgfOZviFlNDa+gVZDK2jvDhV4GtTkdiFahQjsdehMNv8LluNwHvR9U4vCTGQ==; 24:YogLNqrKlPbZUPzc+U/BDYHKLEQWoej9pMUvuT3d/+6yNsom89gLANroYLXDYF6ZC8+W+LLO6bHpiZcI8A7mvMV26LfQ5wSAQaEkpGG18yE=; 7:Dacdw2ngOx7hn2rcfzlItzAPMRePxfo0hYqySUGXYskfVgaGHkCKbJbuAZHZD2maCTPki+EGRA/t2R5P2ZHOEpJO0grCDGzn0wW6aaPQbw5z/WifkpIY4OZRDo6jA1/Q29cNaez4bpjeFqf4awRWRGestW9P3G7xY0YPHpK+R64oZImkFd3HrSCnZvOFKZ/mWN3ftPtyD2TxIxWb45IFmsvmB0YbM1oRvWaNsO2J/eqPq6FiaCOllGhzLaWcBOpy
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2016 11:45:22.7263 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0928
Archived-At: 
Cc: slim@ietf.org, Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org, slim issue tracker 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 11:45:33 -0000

On 2016/08/17 23:13, Gunnar Hellström wrote:
>
>
> Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>>
>>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellström
>>> >
>>> wrote:
>>>
>>> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:


>>> B.  One spoken and one written language
>>> I send an offer with spoken English in audio and written English in
>>> text. I call you, and you have also configured spoken English in
>>> audio and written English in text.
>>> We both prefer to talk if we have a chance.
>>> The negotiation succeeds and you get an indication that audio and
>>> text are the available media. If you do not get any preference
>>> indication, you do not know how to start the call. You may try
>>> English text fist and type "Hi, welcome, what can I do for you". I
>>> notice that you type, so I answer in text, because I do not know if
>>> you can talk English. We might continue the whole call in text, or
>>> take the effort to ask if we can change to talking.
>>> Not until you get to know that we both can use spoken English and
>>> that it is the preferred match, you get a chance to respond in spoken
>>> English and the call starts well. The device can convey the
>>> negotiation result to you without us specifyinng how, but we need to
>>> describe that my preference for spoken modality is conveyed by the
>>> protocol.
>> The protocol exchange informs BOTH ENDS that both voice and text is
>> negotiated.  It’s perfectly fine for either end to start in either
>> modality, and switch any time they want to.
> No that is not perfectly fine. It is inconvenient and awkward to
> communicate in other than your favoured modality. And it is awkward to
> have a dialogue about what alternatives there are. A most simple
> mechanism to configure and convey the modality preference is needed as
> part of our protocol.
>
> You can have even more examples where the solution is to both have a
> favoured modality indication and a way (not specified by us) to convey
> the result of the negotiation to the users.

I'm only trying to extrapolate from my own personal use of current 
(possibly non-standardized) technology like chats and skype and the like.

My observation would be the following:

Language abilities and therefore preferences are more or less fixed 
[There is the case that I'm more familiar to talk about technical 
subjects in English while I'd be more at ease in another language for 
some other topics, but that's definitely something very advanced.]

On the other hand, modality preferences often change very quickly. I may 
wait for a train and be comfortable with voice on the platform, but as 
soon as I board the train, I might prefer to change to text to not annoy 
other passengers (in some places, there's very strong social pressure to 
avoid talking in a train). I might start with something that I think can 
be dealt with in text, to later realize that I need speech to get my 
ideas across. More such situations are easy to come up with, also for video.

So in order to be able to indicate a preferred modality, the system 
might have to check with me continuously, and I might have to update my 
preference very often, or get them wrong lots of time. That to me sounds 
like an argument for not standardizing "favorite modality".

Regards,   Martin.


From nobody Thu Aug 18 09:56:05 2016
Return-Path: 
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 C670C12DA6E; Thu, 18 Aug 2016 09:55:15 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 eBw7wR8AT3-s; Thu, 18 Aug 2016 09:54:35 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E46B912DA5F; Thu, 18 Aug 2016 09:54:24 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 18 Aug 2016 09:54:23 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>   <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Thu, 18 Aug 2016 09:54:21 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Randall Gellens , Brian Rosen , slim issue tracker 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, Natasha Rooney , draft-ietf-slim-negotiating-human-language@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 16:55:16 -0000

At 8:26 AM +0200 8/18/16, Gunnar Hellstr=F6m wrote:

>  Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
>>  At 3:22 PM +0200 8/17/16, Gunnar Hellstr=F6m wrote:
>>
>>>    In order for the call to complete=20
>>> successfully you then need to know that=20
>>> English both ways was selected, so that you=20
>>> start talking English in your answer. It=20
>>> would be a failure of our intentions if you=20
>>> only got a connected indication and needed to=20
>>> start asking me what language I prefer.
>>
>>  Both endpoints know what was set up (English=20
>> audio in your example).  What the endpoints do=20
>> with this knowledge, including if and how they=20
>> communicate it to the user, is out of scope.
>>
>  Yes, agreed. So our task in this draft is to=20
> describe the mechanism that enable the=20
> endpoints to have the information needed for a=20
> successful and smooth start of the call =3D=20
> greeting from the called party in the most=20
> appropriate language and modality.

No, the task is to enable the endpoints to set up=20
the media.  What they do then is up to them.  You=20
might want to write an "advice to implementers"=20
draft that provides information and suggestions=20
to implementers as to how to have a successful=20
call.  But that needs to be an entirely separate=20
and purely informational draft.  In lieu of an=20
IETF draft, you could instead publish the=20
information as a blog post or web page.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The very first "flight attendants" were three 14-year old cabin boys,
who were hired by Great Britain's Daimler Airways in 1922. Passenger
service, rather than safety, was the primary reason these "airborne
bellboys" were included on the flight. Food and beverage service was
not offered on these first flights. Apparently, the reason for these
boys to be in the cabin was more for aesthetics rather than
functionality.
    --airlinesafety.com/editorials/CockpitCabinPsychology.htm


From nobody Thu Aug 18 10:16:09 2016
Return-Path: 
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 4646E12DA05 for ; Thu, 18 Aug 2016 10:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 k5omNcOr1joL for ; Thu, 18 Aug 2016 10:16:02 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6347212DABA for ; Thu, 18 Aug 2016 10:16:02 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id 97so38846710uav.3 for ; Thu, 18 Aug 2016 10:16:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2gjuVAfOdA+BNnbuDa0SOtFGIaH29dYW+O18+C+sQBo=; b=WLjuWUJ+GbtJVilwtVchusI+MJrfnjobvYlf9AKA97GoqD/TioQDLvKSb/1GZP2elR URaYR3Khx2lLxf6IYSM7IvcyU6190Lvwpzo/X846PwvFRk6LIscFWLdUCibU8dW0e9Lm gLl1kWnV9wnMgR8dhv68dFs7wLHrt3TmDoxgGRewwOCA+kw9YKFGroSR4PUn/PlJpfQ+ ttFVbmzeXkxPotGZcD5QN9Tc6pkzDx7pKwxoTTj+p7hyWCGD+MKe6TEQIdp6O5fw8XA+ WHopefAhFdhF/vSbKU7snBsBKg9cJaS/yqb5aGNppAS0b7v0CVpW+isvCi26hCZxQOXN 3bzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2gjuVAfOdA+BNnbuDa0SOtFGIaH29dYW+O18+C+sQBo=; b=Tn062IMvQAsyL84Xn4Ox7YyjjZBaNgPzS71K1KZfAvA50iKX/HXqbD7fBqroiVREEd 0zkHzZax6J5UZGt7dgZar04D4HIRV1JcvYKdZRpi//xANPWlQSZ7TXZpharOEomDzNSh q5LjFF/SeoxoWDY257iNl6ytnftB7ttqxChMe7znlG2O+W66FODDGRIefSPnnPXk1UrO apHX674lMZv6zSE+Q1XX6GQ36ib0RLka6cdPdtKdcR7MSYU1M6W3g4JYUsd1TPo7eIY3 6+aWORYek2R4fcNtQ1eOdykykpW5KZGmjvROE5yxiNNKF9f0DHHLmkWEm8Mge8eaiX94 VYaA==
X-Gm-Message-State: AEkooutAy4LhHOeEdljQxA9lpXPN4aUTQ1u8OgZLFCOQLuXdiNCWudCo4j6Sd9SlLbAlN6lDLZOv/hf8nYLBjg==
X-Received: by 10.176.3.242 with SMTP id 105mr1836353uau.112.1471540560811; Thu, 18 Aug 2016 10:16:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.82.184 with HTTP; Thu, 18 Aug 2016 10:15:40 -0700 (PDT)
In-Reply-To: <55485a96-a691-534c-767c-cedf1660ad7c@it.aoyama.ac.jp>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net> <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se> <55485a96-a691-534c-767c-cedf1660ad7c@it.aoyama.ac.jp>
From: Bernard Aboba 
Date: Thu, 18 Aug 2016 10:15:40 -0700
Message-ID: 
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= 
Content-Type: multipart/alternative; boundary=94eb2c067ea8665b38053a5bbcec
Archived-At: 
Cc: slim@ietf.org, =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= , Brian Rosen 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 17:16:06 -0000

--94eb2c067ea8665b38053a5bbcec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Martin said:

"So in order to be able to indicate a preferred modality, the system might
have to check with me continuously..."

[BA]  Good point. To deal with conditions that can change rapidly, it is
best to avoid signaling if possible, particularly where congestion could be
involved.

 A caller might "prefer" to sign, but discovers that the webcam is not
functioning or connectivity is poor so they switch to using text.  Perhaps
the issue with video clears up, so now they can switch to signing. In these
situations, it could be a burden to signal a change in "preferred modality"
(or even to renegotiate the media), particularly if congestion is severe
enough to cause delays in signaling or even signaling failure. It might be
more convenient to handle these temporary conditions by "muting" or
"unmuting" media, or changing aspects of the media encoding (e.g. lowering
resolution or dropping spatial layers but maintaining framerate to protect
the viability of signing), rather than signaling. This is why we have an
RTCP message (PAUSED) or a codec-specific message (SEI layer drop) to
indicate that a peer is dropping a stream or layer, which makes it possible
to avoid signaling this in SDP.

On Thu, Aug 18, 2016 at 4:45 AM, Martin J. D=C3=BCrst 
wrote:

>
>
> On 2016/08/17 23:13, Gunnar Hellstr=C3=B6m wrote:
>
>>
>>
>> Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>>
>>>
>>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=C3=B6m
>>>> >
>>>> wrote:
>>>>
>>>> Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>>>>
>>>
>
> B.  One spoken and one written language
>>>> I send an offer with spoken English in audio and written English in
>>>> text. I call you, and you have also configured spoken English in
>>>> audio and written English in text.
>>>> We both prefer to talk if we have a chance.
>>>> The negotiation succeeds and you get an indication that audio and
>>>> text are the available media. If you do not get any preference
>>>> indication, you do not know how to start the call. You may try
>>>> English text fist and type "Hi, welcome, what can I do for you". I
>>>> notice that you type, so I answer in text, because I do not know if
>>>> you can talk English. We might continue the whole call in text, or
>>>> take the effort to ask if we can change to talking.
>>>> Not until you get to know that we both can use spoken English and
>>>> that it is the preferred match, you get a chance to respond in spoken
>>>> English and the call starts well. The device can convey the
>>>> negotiation result to you without us specifyinng how, but we need to
>>>> describe that my preference for spoken modality is conveyed by the
>>>> protocol.
>>>>
>>> The protocol exchange informs BOTH ENDS that both voice and text is
>>> negotiated.  It=E2=80=99s perfectly fine for either end to start in eit=
her
>>> modality, and switch any time they want to.
>>>
>> No that is not perfectly fine. It is inconvenient and awkward to
>> communicate in other than your favoured modality. And it is awkward to
>> have a dialogue about what alternatives there are. A most simple
>> mechanism to configure and convey the modality preference is needed as
>> part of our protocol.
>>
>> You can have even more examples where the solution is to both have a
>> favoured modality indication and a way (not specified by us) to convey
>> the result of the negotiation to the users.
>>
>
> I'm only trying to extrapolate from my own personal use of current
> (possibly non-standardized) technology like chats and skype and the like.
>
> My observation would be the following:
>
> Language abilities and therefore preferences are more or less fixed [Ther=
e
> is the case that I'm more familiar to talk about technical subjects in
> English while I'd be more at ease in another language for some other
> topics, but that's definitely something very advanced.]
>
> On the other hand, modality preferences often change very quickly. I may
> wait for a train and be comfortable with voice on the platform, but as so=
on
> as I board the train, I might prefer to change to text to not annoy other
> passengers (in some places, there's very strong social pressure to avoid
> talking in a train). I might start with something that I think can be dea=
lt
> with in text, to later realize that I need speech to get my ideas across.
> More such situations are easy to come up with, also for video.
>
> So in order to be able to indicate a preferred modality, the system might
> have to check with me continuously, and I might have to update my
> preference very often, or get them wrong lots of time. That to me sounds
> like an argument for not standardizing "favorite modality".
>
> Regards,   Martin.
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

--94eb2c067ea8665b38053a5bbcec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Martin said:=C2=A0

"So in order to=
 be able to indicate a preferred modality, the system might have to check w=
ith me continuously..."

[BA] =C2=A0Good point=
. To deal with conditions that can change rapidly, it is best to avoid sign=
aling if possible, particularly where congestion could be involved. =C2=A0<=
/div>

=C2=A0A caller might "prefer" to sign, b=
ut discovers that the webcam is not functioning or connectivity is poor so =
they switch to using text.=C2=A0 Perhaps the issue with video clears up, so=
 now they can switch to signing. In these situations, it could be a burden =
to signal a change in "preferred modality" (or even to renegotiat=
e the media), particularly if congestion is severe enough to cause delays i=
n signaling or even signaling failure. It might be more convenient to handl=
e these temporary conditions by "muting" or "unmuting" =
media, or changing aspects of the media encoding (e.g. lowering resolution =
or dropping spatial layers but maintaining framerate to protect the viabili=
ty of signing), rather than signaling. This is why we have an RTCP message =
(PAUSED) or a codec-specific message (SEI layer drop) to indicate that a pe=
er is dropping a stream or layer, which makes it possible to avoid signalin=
g this in SDP. =C2=A0

On Thu, Aug 18, 2016 at 4:45 AM, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:




On 2016/08/17 23:13, Gunnar Hellstr=C3=B6m wrote:







Den 2016-08-17 kl. 15:35, skrev Brian Rosen:







On Aug 17, 2016, at 9:22 AM, Gunnar Hellstr=C3=B6m

<gunnar=
.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>>

wrote:



Den 2016-08-16 kl. 23:50, skrev Brian Rosen:









B.=C2=A0 One spoken and one written language

I send an offer with spoken English in audio and written English in

text. I call you, and you have also configured spoken English in

audio and written English in text.

We both prefer to talk if we have a chance.

The negotiation succeeds and you get an indication that audio and

text are the available media. If you do not get any preference

indication, you do not know how to start the call. You may try

English text fist and type "Hi, welcome, what can I do for you". =
I

notice that you type, so I answer in text, because I do not know if

you can talk English. We might continue the whole call in text, or

take the effort to ask if we can change to talking.

Not until you get to know that we both can use spoken English and

that it is the preferred match, you get a chance to respond in spoken

English and the call starts well. The device can convey the

negotiation result to you without us specifyinng how, but we need to

describe that my preference for spoken modality is conveyed by the

protocol.



The protocol exchange informs BOTH ENDS that both voice and text is

negotiated.=C2=A0 It=E2=80=99s perfectly fine for either end to start in ei=
ther

modality, and switch any time they want to.



No that is not perfectly fine. It is inconvenient and awkward to

communicate in other than your favoured modality. And it is awkward to

have a dialogue about what alternatives there are. A most simple

mechanism to configure and convey the modality preference is needed as

part of our protocol.



You can have even more examples where the solution is to both have a

favoured modality indication and a way (not specified by us) to convey

the result of the negotiation to the users.





I'm only trying to extrapolate from my own personal use of current (pos=
sibly non-standardized) technology like chats and skype and the like.



My observation would be the following:



Language abilities and therefore preferences are more or less fixed [There =
is the case that I'm more familiar to talk about technical subjects in =
English while I'd be more at ease in another language for some other to=
pics, but that's definitely something very advanced.]



On the other hand, modality preferences often change very quickly. I may wa=
it for a train and be comfortable with voice on the platform, but as soon a=
s I board the train, I might prefer to change to text to not annoy other pa=
ssengers (in some places, there's very strong social pressure to avoid =
talking in a train). I might start with something that I think can be dealt=
 with in text, to later realize that I need speech to get my ideas across. =
More such situations are easy to come up with, also for video.



So in order to be able to indicate a preferred modality, the system might h=
ave to check with me continuously, and I might have to update my preference=
 very often, or get them wrong lots of time. That to me sounds like an argu=
ment for not standardizing "favorite modality".



Regards,=C2=A0 =C2=A0Martin.




_______________________________________________

SLIM mailing list

SLIM@ietf.org

https://www.ietf.org/mailman/listinfo/slim





--94eb2c067ea8665b38053a5bbcec--


From nobody Thu Aug 18 13:11:51 2016
Return-Path: 
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 30C4412DA35 for ; Thu, 18 Aug 2016 13:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 LkXLYu0t6JxR for ; Thu, 18 Aug 2016 13:11:46 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 4F6E912DA3F for ; Thu, 18 Aug 2016 13:11:43 -0700 (PDT)
X-Halon-ID: f71f0f80-657f-11e6-b846-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 18 Aug 2016 22:11:35 +0200 (CEST)
To: Bernard Aboba , slim@ietf.org
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>  <5FE15A5B-750C-4831-B5C3-C51450E4D50B@brianrosen.net> <69964b96-1019-c74e-dd7e-003913bb226d@omnitor.se> <55485a96-a691-534c-767c-cedf1660ad7c@it.aoyama.ac.jp> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <452171ab-437c-3c89-6c9e-9377ab0e9fcb@omnitor.se>
Date: Thu, 18 Aug 2016 22:11:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------ECA14DAED22E3008C85650AE"
Archived-At: 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 20:11:50 -0000

This is a multi-part message in MIME format.
--------------ECA14DAED22E3008C85650AE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Den 2016-08-18 kl. 19:15, skrev Bernard Aboba:

> Martin said:
>
> "So in order to be able to indicate a preferred modality, the system 
> might have to check with me continuously..."
>
> [BA]  Good point. To deal with conditions that can change rapidly, it 
> is best to avoid signaling if possible, particularly where congestion 
> could be involved.
Yes, such situations may occur, and various solutions can be made to 
handle such cases smoothly. One simple solution is of course that for 
the cases when you select to make a text call without video, then your 
setting for sign language as the preferred modality is not included 
because it would have been included with the m=video media description.
There are other solutions on the same situation where you still have 
benefit of the modality preference indication to make the calling more 
convenient than it is today.
And you may of course also select to not do any modality preference 
setting and get answered in a random modality.

On the other hand, there are many users with quite stable conditions who 
want the convenience of the requirement that Paul stated:
"When I call a call center I want to be directed automatically to 
someone who speaks my language and then be greeted in a language I speak."

If the Dutch and French relay services still are as I latest saw them 
working, they start the call with asking the user if sign language or 
real-time text relaying is wanted, and the user needs to enter a simple 
text response before getting connected. It is a possible mechanism 
today, but our draft should offer a possibility to automate that mechanism.

So, we shall not avoid standardizing a good function just because there 
are cases when you can do reasonably without it.

/Gunnar

>
>  A caller might "prefer" to sign, but discovers that the webcam is not 
> functioning or connectivity is poor so they switch to using text.  
> Perhaps the issue with video clears up, so now they can switch to 
> signing. In these situations, it could be a burden to signal a change 
> in "preferred modality" (or even to renegotiate the media), 
> particularly if congestion is severe enough to cause delays in 
> signaling or even signaling failure. It might be more convenient to 
> handle these temporary conditions by "muting" or "unmuting" media, or 
> changing aspects of the media encoding (e.g. lowering resolution or 
> dropping spatial layers but maintaining framerate to protect the 
> viability of signing), rather than signaling. This is why we have an 
> RTCP message (PAUSED) or a codec-specific message (SEI layer drop) to 
> indicate that a peer is dropping a stream or layer, which makes it 
> possible to avoid signaling this in SDP.
>
> On Thu, Aug 18, 2016 at 4:45 AM, Martin J. Dürst 
> > wrote:
>
>
>
>     On 2016/08/17 23:13, Gunnar Hellström wrote:
>
>
>
>         Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>
>
>                 On Aug 17, 2016, at 9:22 AM, Gunnar Hellström
>                                  
>                                  >>
>                 wrote:
>
>                 Den 2016-08-16 kl. 23:50, skrev Brian Rosen:
>
>
>
>                 B.  One spoken and one written language
>                 I send an offer with spoken English in audio and
>                 written English in
>                 text. I call you, and you have also configured spoken
>                 English in
>                 audio and written English in text.
>                 We both prefer to talk if we have a chance.
>                 The negotiation succeeds and you get an indication
>                 that audio and
>                 text are the available media. If you do not get any
>                 preference
>                 indication, you do not know how to start the call. You
>                 may try
>                 English text fist and type "Hi, welcome, what can I do
>                 for you". I
>                 notice that you type, so I answer in text, because I
>                 do not know if
>                 you can talk English. We might continue the whole call
>                 in text, or
>                 take the effort to ask if we can change to talking.
>                 Not until you get to know that we both can use spoken
>                 English and
>                 that it is the preferred match, you get a chance to
>                 respond in spoken
>                 English and the call starts well. The device can
>                 convey the
>                 negotiation result to you without us specifyinng how,
>                 but we need to
>                 describe that my preference for spoken modality is
>                 conveyed by the
>                 protocol.
>
>             The protocol exchange informs BOTH ENDS that both voice
>             and text is
>             negotiated.  It’s perfectly fine for either end to start
>             in either
>             modality, and switch any time they want to.
>
>         No that is not perfectly fine. It is inconvenient and awkward to
>         communicate in other than your favoured modality. And it is
>         awkward to
>         have a dialogue about what alternatives there are. A most simple
>         mechanism to configure and convey the modality preference is
>         needed as
>         part of our protocol.
>
>         You can have even more examples where the solution is to both
>         have a
>         favoured modality indication and a way (not specified by us)
>         to convey
>         the result of the negotiation to the users.
>
>
>     I'm only trying to extrapolate from my own personal use of current
>     (possibly non-standardized) technology like chats and skype and
>     the like.
>
>     My observation would be the following:
>
>     Language abilities and therefore preferences are more or less
>     fixed [There is the case that I'm more familiar to talk about
>     technical subjects in English while I'd be more at ease in another
>     language for some other topics, but that's definitely something
>     very advanced.]
>
>     On the other hand, modality preferences often change very quickly.
>     I may wait for a train and be comfortable with voice on the
>     platform, but as soon as I board the train, I might prefer to
>     change to text to not annoy other passengers (in some places,
>     there's very strong social pressure to avoid talking in a train).
>     I might start with something that I think can be dealt with in
>     text, to later realize that I need speech to get my ideas across.
>     More such situations are easy to come up with, also for video.
>
>     So in order to be able to indicate a preferred modality, the
>     system might have to check with me continuously, and I might have
>     to update my preference very often, or get them wrong lots of
>     time. That to me sounds like an argument for not standardizing
>     "favorite modality".
>
>     Regards,   Martin.
>
>
>     _______________________________________________
>     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


--------------ECA14DAED22E3008C85650AE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Den 2016-08-18 kl. 19:15, skrev Bernard Aboba:

    

    

      
Martin said: 
        


        

        
"So in order to be able to indicate a preferred modality,
          the system might have to check with me continuously..."

        


        

        
[BA]  Good point. To deal with conditions that can change
          rapidly, it is best to avoid signaling if possible,
          particularly where congestion could be involved. 

      

    

    Yes, such situations may occur, and various solutions can be made to
    handle such cases smoothly. One simple solution is of course that
    for the cases when you select to make a text call without video,
    then your setting for sign language as the preferred modality is not
    included because it would have been included with the m=video media
    description. 

    There are other solutions on the same situation where you still have
    benefit of the modality preference indication to make the calling
    more convenient than it is today. 

    And you may of course also select to not do any modality preference
    setting and get answered in a random modality. 

    

    On the other hand, there are many users with quite stable conditions
    who want the convenience of the requirement that Paul stated:

    "When I call a call center I want to be directed automatically to
    someone who speaks my language and then be greeted in a language I
    speak."

    

    If the Dutch and French relay services still are as I latest saw
    them working, they start the call with asking the user if sign
    language or real-time text relaying is wanted, and the user needs to
    enter a simple text response before getting connected. It is a
    possible mechanism today, but our draft should offer a possibility
    to automate that mechanism. 

    

    So, we shall not avoid standardizing a good function just because
    there are cases when you can do reasonably without it. 

    

    /Gunnar 

    

     
    

      

        
 

        


        

        
 A caller might "prefer" to sign, but discovers that the
          webcam is not functioning or connectivity is poor so they
          switch to using text.  Perhaps the issue with video clears up,
          so now they can switch to signing. In these situations, it
          could be a burden to signal a change in "preferred modality"
          (or even to renegotiate the media), particularly if congestion
          is severe enough to cause delays in signaling or even
          signaling failure. It might be more convenient to handle these
          temporary conditions by "muting" or "unmuting" media, or
          changing aspects of the media encoding (e.g. lowering
          resolution or dropping spatial layers but maintaining
          framerate to protect the viability of signing), rather than
          signaling. This is why we have an RTCP message (PAUSED) or a
          codec-specific message (SEI layer drop) to indicate that a
          peer is dropping a stream or layer, which makes it possible to
          avoid signaling this in SDP.  

      

      


        
On Thu, Aug 18, 2016 at 4:45 AM, Martin
          J. Dürst <duerst@it.aoyama.ac.jp>
          wrote:

          


              

              On 2016/08/17 23:13, Gunnar Hellström wrote:

            
            

                

                

                Den 2016-08-17 kl. 15:35, skrev Brian Rosen:

              
              

                

                

                    On Aug 17, 2016, at 9:22 AM, Gunnar Hellström

                  
                  <gunnar.hellstrom@omnitor.se
                  <mailto:gunnar.hellstrom@omnitor.se>>

                    wrote:

                    

                    Den 2016-08-16 kl. 23:50, skrev Brian Rosen:

                  

              

            

            

              

                

                

                

                  

                    

                      B.  One spoken and one written language

                      I send an offer with spoken English in audio and
                      written English in

                      text. I call you, and you have also configured
                      spoken English in

                      audio and written English in text.

                      We both prefer to talk if we have a chance.

                      The negotiation succeeds and you get an indication
                      that audio and

                      text are the available media. If you do not get
                      any preference

                      indication, you do not know how to start the call.
                      You may try

                      English text fist and type "Hi, welcome, what can
                      I do for you". I

                      notice that you type, so I answer in text, because
                      I do not know if

                      you can talk English. We might continue the whole
                      call in text, or

                      take the effort to ask if we can change to
                      talking.

                      Not until you get to know that we both can use
                      spoken English and

                      that it is the preferred match, you get a chance
                      to respond in spoken

                      English and the call starts well. The device can
                      convey the

                      negotiation result to you without us specifyinng
                      how, but we need to

                      describe that my preference for spoken modality is
                      conveyed by the

                      protocol.

                    

                    The protocol exchange informs BOTH ENDS that both
                    voice and text is

                    negotiated.  It’s perfectly fine for either end to
                    start in either

                    modality, and switch any time they want to.

                  

                  No that is not perfectly fine. It is inconvenient and
                  awkward to

                  communicate in other than your favoured modality. And
                  it is awkward to

                  have a dialogue about what alternatives there are. A
                  most simple

                  mechanism to configure and convey the modality
                  preference is needed as

                  part of our protocol.

                  

                  You can have even more examples where the solution is
                  to both have a

                  favoured modality indication and a way (not specified
                  by us) to convey

                  the result of the negotiation to the users.

                

                

              

            

            I'm only trying to extrapolate from my own personal use of
            current (possibly non-standardized) technology like chats
            and skype and the like.

            

            My observation would be the following:

            

            Language abilities and therefore preferences are more or
            less fixed [There is the case that I'm more familiar to talk
            about technical subjects in English while I'd be more at
            ease in another language for some other topics, but that's
            definitely something very advanced.]

            

            On the other hand, modality preferences often change very
            quickly. I may wait for a train and be comfortable with
            voice on the platform, but as soon as I board the train, I
            might prefer to change to text to not annoy other passengers
            (in some places, there's very strong social pressure to
            avoid talking in a train). I might start with something that
            I think can be dealt with in text, to later realize that I
            need speech to get my ideas across. More such situations are
            easy to come up with, also for video.

            

            So in order to be able to indicate a preferred modality, the
            system might have to check with me continuously, and I might
            have to update my preference very often, or get them wrong
            lots of time. That to me sounds like an argument for not
            standardizing "favorite modality".

            

            Regards,   Martin.
            

              


                

                _______________________________________________

                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

  


--------------ECA14DAED22E3008C85650AE--


From nobody Thu Aug 18 13:30:40 2016
Return-Path: 
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 2A34D12DB17 for ; Thu, 18 Aug 2016 13:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 tk98ytxr74cg for ; Thu, 18 Aug 2016 13:30:36 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 5545112DB07 for ; Thu, 18 Aug 2016 13:30:36 -0700 (PDT)
X-Halon-ID: 9dd50128-6582-11e6-be68-005056913f0f
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 18 Aug 2016 22:30:34 +0200 (CEST)
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>   <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se> 
To: "slim@ietf.org" , slim@ietf.org
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <5765d3d8-04fe-b2f5-19bb-5628dd6c57d2@omnitor.se>
Date: Thu, 18 Aug 2016 22:30:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 20:30:39 -0000

Den 2016-08-18 kl. 18:54, skrev Randall Gellens:

> At 8:26 AM +0200 8/18/16, Gunnar Hellström wrote:
>
>>  Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
>>>  At 3:22 PM +0200 8/17/16, Gunnar Hellström wrote:
>>>
>>>>    In order for the call to complete successfully you then need to 
>>>> know that English both ways was selected, so that you start talking 
>>>> English in your answer. It would be a failure of our intentions if 
>>>> you only got a connected indication and needed to start asking me 
>>>> what language I prefer.
>>>
>>>  Both endpoints know what was set up (English audio in your 
>>> example).  What the endpoints do with this knowledge, including if 
>>> and how they communicate it to the user, is out of scope.
>>>
>>  Yes, agreed. So our task in this draft is to describe the mechanism 
>> that enable the endpoints to have the information needed for a 
>> successful and smooth start of the call = greeting from the called 
>> party in the most appropriate language and modality.
>
> No, the task is to enable the endpoints to set up the media.
This is not about setting up media. It is about conveying info to the 
endpoints about what language to fill the media connections with. We 
have said many times that media included in the offer are wanted anyway 
even if they are not used for language.
The role for what we do for language is similar to what RFC 4796 The SDP 
Contents Attribute does for content types. It provides additional 
information about the media to both endpoints.
In our case the information provided shall be sufficient for starting 
the call in an appropriate language and modality. We do not say how the 
result of the negotiation is provided to the "language generating 
entity", we just convey it to the endpoint ( or terminal or UA or 
client, whatever we want to call it ) but the information needs to be 
sufficient to give most cases proper base for the decision.
>   What they do then is up to them.  You might want to write an "advice 
> to implementers" draft that provides information and suggestions to 
> implementers as to how to have a successful call.  But that needs to 
> be an entirely separate and purely informational draft.  In lieu of an 
> IETF draft, you could instead publish the information as a blog post 
> or web page.
Yes, why is this repeated so many times?
Let us instead complete the task to decide on information and syntax to 
convey between the endpoints.

/Gunnar
>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


From nobody Fri Aug 19 00:19:11 2016
Return-Path: 
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 E984712D536 for ; Fri, 19 Aug 2016 00:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 aQl-epmKqkAv for ; Fri, 19 Aug 2016 00:19:06 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 8FAD612D08E for ; Fri, 19 Aug 2016 00:19:05 -0700 (PDT)
X-Halon-ID: 34d06b58-65dd-11e6-be68-005056913f0f
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 19 Aug 2016 09:19:02 +0200 (CEST)
To: slim@ietf.org
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>   <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>  <5765d3d8-04fe-b2f5-19bb-5628dd6c57d2@omnitor.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Fri, 19 Aug 2016 09:18:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <5765d3d8-04fe-b2f5-19bb-5628dd6c57d2@omnitor.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 07:19:09 -0000

It is amazing that we have not yet been able to solve the need for 
preference indication independent of media.

We have been discussing it for 40 months (!), the surrounding standards 
requiring it have defined that they need the function but cannot go on 
to detail stage 3 of how to use our specification for this need.

With the current draft I can specify that I prefer to speak English but 
can also with lower preference accept to speak French.

But I cannot specify that I prefer to sign BSL (British Sign Language) 
but can also with lower preference accept to read and write English. I 
do not see any logic in making that difference. It is just an incomplete 
specification. And, since the examples about routing and setting up 
calls are preferred in this discussion, I can take a simple example from 
when this indication is useful:

We have directives in force in Europe saying that all shall be equally 
well taken care of by emergency services.

1. Person A prefers to use written English but knows BSL. (BSL is 
included in the capability indication so that calls with friends can be 
held in BSL without any relay service coming into the call)

2. Person B prefers BSL but can accept to use written English. (Written 
English is included in the capability indication so that calls with 
hearing people with text capability can be held in text without a relay 
service coming into the call )

3. An emergency service has a small group of people who communicate well 
in BSL and other call-takers who speak and type English.

4. When user B calls emergency service, the call should be routed to the 
small group knowing sign language well and the call should start in BSL.

5. When user A calls emergency service, the call should be routed to the 
general call-takers who have text and spoken capabilities.

6. With a method for preference indication between written English and 
BSL, the ESInet can do the routing and send each call to the group most 
suited to take it.

7. Without a method for distinguishing the priorities between the two 
users, there is no way to route the calls to appropriate call-takers.

Many other similar examples can be made, from emergency calling as well 
as everyday calling.
So let us solve this need in the draft. I have proposed about 4 
notations, with gradually reduced functionality, but still capable of 
solving the most apparent needs. They are depending on what syntax we 
take for the attributes, so let us try to decide on both the attribute 
syntax and the most favoured modality indication syntax together.

/Gunnar


Den 2016-08-18 kl. 22:30, skrev Gunnar Hellström:
> Den 2016-08-18 kl. 18:54, skrev Randall Gellens:
>
>> At 8:26 AM +0200 8/18/16, Gunnar Hellström wrote:
>>
>>>  Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
>>>>  At 3:22 PM +0200 8/17/16, Gunnar Hellström wrote:
>>>>
>>>>>    In order for the call to complete successfully you then need to 
>>>>> know that English both ways was selected, so that you start 
>>>>> talking English in your answer. It would be a failure of our 
>>>>> intentions if you only got a connected indication and needed to 
>>>>> start asking me what language I prefer.
>>>>
>>>>  Both endpoints know what was set up (English audio in your 
>>>> example).  What the endpoints do with this knowledge, including if 
>>>> and how they communicate it to the user, is out of scope.
>>>>
>>>  Yes, agreed. So our task in this draft is to describe the mechanism 
>>> that enable the endpoints to have the information needed for a 
>>> successful and smooth start of the call = greeting from the called 
>>> party in the most appropriate language and modality.
>>
>> No, the task is to enable the endpoints to set up the media.
> This is not about setting up media. It is about conveying info to the 
> endpoints about what language to fill the media connections with. We 
> have said many times that media included in the offer are wanted 
> anyway even if they are not used for language.
> The role for what we do for language is similar to what RFC 4796 The 
> SDP Contents Attribute does for content types. It provides additional 
> information about the media to both endpoints.
> In our case the information provided shall be sufficient for starting 
> the call in an appropriate language and modality. We do not say how 
> the result of the negotiation is provided to the "language generating 
> entity", we just convey it to the endpoint ( or terminal or UA or 
> client, whatever we want to call it ) but the information needs to be 
> sufficient to give most cases proper base for the decision.
>>   What they do then is up to them.  You might want to write an 
>> "advice to implementers" draft that provides information and 
>> suggestions to implementers as to how to have a successful call.  But 
>> that needs to be an entirely separate and purely informational 
>> draft.  In lieu of an IETF draft, you could instead publish the 
>> information as a blog post or web page.
> Yes, why is this repeated so many times?
> Let us instead complete the task to decide on information and syntax 
> to convey between the endpoints.
>
> /Gunnar
>>
>>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


From nobody Fri Aug 19 02:35:12 2016
Return-Path: 
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 0E3C312B064 for ; Fri, 19 Aug 2016 02:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 V-xUquW72XLL for ; Fri, 19 Aug 2016 02:35:08 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD0012DD1B for ; Fri, 19 Aug 2016 02:35:08 -0700 (PDT)
Received: from localhost ([::1]:40420 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bagCh-0002ay-IQ; Fri, 19 Aug 2016 02:35:07 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: nrooney@gsma.com
X-Trac-Project: slim
Date: Fri, 19 Aug 2016 09:35:07 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/1#comment:1
Message-ID: <071.e413fb9c97912992d575672c65a7cba5@tools.ietf.org>
References: <056.9637e749e77ad366b5b024d984b766a3@tools.ietf.org>
X-Trac-Ticket-ID: 1
In-Reply-To: <056.9637e749e77ad366b5b024d984b766a3@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: nrooney@gsma.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #1 (use-cases): Test ticket
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 09:35:10 -0000

#1: Test ticket

Changes (by nrooney@gsma.com):

 * status:  new => closed
 * resolution:   => invalid


-- 
--------------------------------+-----------------------------
 Reporter:  nrooney@gsma.com    |       Owner:  Natasha Rooney
     Type:  task                |      Status:  closed
 Priority:  trivial             |   Milestone:  milestone1
Component:  use-cases           |     Version:  1.0
 Severity:  Active WG Document  |  Resolution:  invalid
 Keywords:                      |
--------------------------------+-----------------------------

Ticket URL: 
slim 


From nobody Fri Aug 19 02:59:19 2016
Return-Path: 
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 B252612DDA1; Fri, 19 Aug 2016 02:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 xaUTbSU00nWr; Fri, 19 Aug 2016 02:59:15 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC28512DD81; Fri, 19 Aug 2016 02:59:15 -0700 (PDT)
Received: from localhost ([::1]:40811 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bagZy-0003Hg-3H; Fri, 19 Aug 2016 02:59:10 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, doug@ewellic.org, nrooney@gsma.com
X-Trac-Project: slim
Date: Fri, 19 Aug 2016 09:59:10 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/14#comment:3
Message-ID: <071.00d5b679d42c7500d1c8b183ac66872f@tools.ietf.org>
References: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org>
X-Trac-Ticket-ID: 14
In-Reply-To: <056.19542737f9c56421eda2d19b80d132c0@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-slim-negotiating-human-language@ietf.org, gunnar.hellstrom@omnitor.se, doug@ewellic.org, nrooney@gsma.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-slim-negotiating-human-language@ietf.org
Resent-Message-Id: <20160819095915.DC28512DD81@ietfa.amsl.com>
Resent-Date: Fri, 19 Aug 2016 02:59:15 -0700 (PDT)
Resent-From: trac+slim@tools.ietf.org
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #14 (negotiating-human-language): Expand acronyms
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 09:59:18 -0000

#14: Expand acronyms


Comment (by nrooney@gsma.com):

 [NR] I'll leave this ticket open for now so the author knows to check
 acronyms.

-- 
-------------------------------------+-------------------------------------
 Reporter:  doug@ewellic.org         |       Owner:  draft-ietf-slim-
     Type:  enhancement              |  negotiating-human-language@ietf.org
 Priority:  minor                    |      Status:  new
Component:  negotiating-human-       |   Milestone:
  language                           |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim 


From nobody Fri Aug 19 06:41:05 2016
Return-Path: 
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 5A5A312D124 for ; Fri, 19 Aug 2016 06:41:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 86bYlPXu8vGi for ; Fri, 19 Aug 2016 06:41:00 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FDD12DA0F for ; Fri, 19 Aug 2016 06:38:59 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id l2so44109123qkf.3 for ; Fri, 19 Aug 2016 06:38:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yf6LNLUVMk5V58N7fMu+X1NiYK/RRj1JsPm+pLjf50k=; b=T8gLua6fBjADsgUN3IIucMNw0J7/EhggGoNXvrYL6saJVhykuWBOKpBjXDsiAZ3rrx +mNSabTYUxy41HlBnSC5yTM9fherGGFNyXgD5PtI0v+DcCaU8deYT4cTGMnm01YVJmb5 MM0Hd43uA1UURXZeX8wgtbX/+8hEEtnQpZPUa/KpkN9nvGe6v11UXuAGYYrVd5MF83La z3sxjD3R5qIsQmK5hW9hN9gB92wzJAuTWvmyuZeEhxIzfQ0SkHgZOFoC617bVoUIGYuW AkmuiGBS5nYEm+OYVrvKq0gHnekL51UastsSE9U5v9+DGrSLLefADc6CSvPpyfuTxTCO +Efw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yf6LNLUVMk5V58N7fMu+X1NiYK/RRj1JsPm+pLjf50k=; b=MqUeYNhc971QZqDzMzUo0D+MTizIPSuZsZiofMLlOx5YqvR9fUT+UFr8t/zL5EI0Cj kFgNTLBy46nn5cqL5a/udACJNXC8GLTMuBUCa2R2XEXoeCU40wh/meVQigRy5TpAnOuP 5QbhFzCfZm+2YUATKMOyy4YMQCtqc9D4mEyW1dYweemQCEJnO9Rznyuj88d9dfcWgTEr O3GjFBVmqNTLvGsUoWM1gFGujg5rxUNpbi3jZplM1I7SRLwWh9ZomzuOghn6zdFYu+MO eULUZaBghOM7WTIFeVUnaBd/0wzLPmR/9w1c4BA1tCn1QpSETUAhdbIjcPqq8MfXpfSI wBgg==
X-Gm-Message-State: AE9vXwO5fM17jSi44fSx3oZ0rG1DEevpvNMsV7WVsewhyahnffhmRsZ0PeqbkoweuCnQ5Q==
X-Received: by 10.55.215.199 with SMTP id t68mr8939380qkt.272.1471613938551; Fri, 19 Aug 2016 06:38:58 -0700 (PDT)
Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id v126sm3830978qkh.30.2016.08.19.06.38.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Aug 2016 06:38:58 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: 
Date: Fri, 19 Aug 2016 09:38:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <80C22112-455A-4B63-BBB8-AACE332095C5@brianrosen.net>
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>   <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>  <5765d3d8-04fe-b2f5-19bb-5628dd6c57d2@omnitor.se> 
To: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 13:41:04 -0000

You differentiate by setting English video with higher priority than BSL =
video for A, while only sending BSL video for B.  You send english text =
for both.  You probably send English audio for A.  The right thing =
happens.

You have never provided a believable example that requires what you are =
asking for.  Every example has a reasonable solution that doesn=92t need =
any more mechanism.  I=92ll agree there are some examples where it may =
make the situation somewhat more optimal, but the result without any =
more mechanism is fine, human=92s being as adaptable as they are.

We=92re trying to keep the mechanism simple by treating each m line =
independent of other m lines.  It=92s a reasonable position to take. =20

I did think about suggesting that BSL audio for an emergency call is an =
interesting request.  It means =93I=92m deaf, but I have an audio =
channel, so if you wanted to hear my background audio, go ahead and set =
it up, but don=92t expect to be able to speak to me=94.

Brian

> On Aug 19, 2016, at 3:18 AM, Gunnar Hellstr=F6m =
 wrote:
>=20
> It is amazing that we have not yet been able to solve the need for =
preference indication independent of media.
>=20
> We have been discussing it for 40 months (!), the surrounding =
standards requiring it have defined that they need the function but =
cannot go on to detail stage 3 of how to use our specification for this =
need.
>=20
> With the current draft I can specify that I prefer to speak English =
but can also with lower preference accept to speak French.
>=20
> But I cannot specify that I prefer to sign BSL (British Sign Language) =
but can also with lower preference accept to read and write English. I =
do not see any logic in making that difference. It is just an incomplete =
specification. And, since the examples about routing and setting up =
calls are preferred in this discussion, I can take a simple example from =
when this indication is useful:
>=20
> We have directives in force in Europe saying that all shall be equally =
well taken care of by emergency services.
>=20
> 1. Person A prefers to use written English but knows BSL. (BSL is =
included in the capability indication so that calls with friends can be =
held in BSL without any relay service coming into the call)
>=20
> 2. Person B prefers BSL but can accept to use written English. =
(Written English is included in the capability indication so that calls =
with hearing people with text capability can be held in text without a =
relay service coming into the call )
>=20
> 3. An emergency service has a small group of people who communicate =
well in BSL and other call-takers who speak and type English.
>=20
> 4. When user B calls emergency service, the call should be routed to =
the small group knowing sign language well and the call should start in =
BSL.
>=20
> 5. When user A calls emergency service, the call should be routed to =
the general call-takers who have text and spoken capabilities.
>=20
> 6. With a method for preference indication between written English and =
BSL, the ESInet can do the routing and send each call to the group most =
suited to take it.
>=20
> 7. Without a method for distinguishing the priorities between the two =
users, there is no way to route the calls to appropriate call-takers.
>=20
> Many other similar examples can be made, from emergency calling as =
well as everyday calling.
> So let us solve this need in the draft. I have proposed about 4 =
notations, with gradually reduced functionality, but still capable of =
solving the most apparent needs. They are depending on what syntax we =
take for the attributes, so let us try to decide on both the attribute =
syntax and the most favoured modality indication syntax together.
>=20
> /Gunnar
>=20
>=20
> Den 2016-08-18 kl. 22:30, skrev Gunnar Hellstr=F6m:
>> Den 2016-08-18 kl. 18:54, skrev Randall Gellens:
>>=20
>>> At 8:26 AM +0200 8/18/16, Gunnar Hellstr=F6m wrote:
>>>=20
>>>> Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
>>>>> At 3:22 PM +0200 8/17/16, Gunnar Hellstr=F6m wrote:
>>>>>=20
>>>>>>   In order for the call to complete successfully you then need to =
know that English both ways was selected, so that you start talking =
English in your answer. It would be a failure of our intentions if you =
only got a connected indication and needed to start asking me what =
language I prefer.
>>>>>=20
>>>>> Both endpoints know what was set up (English audio in your =
example).  What the endpoints do with this knowledge, including if and =
how they communicate it to the user, is out of scope.
>>>>>=20
>>>> Yes, agreed. So our task in this draft is to describe the mechanism =
that enable the endpoints to have the information needed for a =
successful and smooth start of the call =3D greeting from the called =
party in the most appropriate language and modality.
>>>=20
>>> No, the task is to enable the endpoints to set up the media.
>> This is not about setting up media. It is about conveying info to the =
endpoints about what language to fill the media connections with. We =
have said many times that media included in the offer are wanted anyway =
even if they are not used for language.
>> The role for what we do for language is similar to what RFC 4796 The =
SDP Contents Attribute does for content types. It provides additional =
information about the media to both endpoints.
>> In our case the information provided shall be sufficient for starting =
the call in an appropriate language and modality. We do not say how the =
result of the negotiation is provided to the "language generating =
entity", we just convey it to the endpoint ( or terminal or UA or =
client, whatever we want to call it ) but the information needs to be =
sufficient to give most cases proper base for the decision.
>>>  What they do then is up to them.  You might want to write an =
"advice to implementers" draft that provides information and suggestions =
to implementers as to how to have a successful call.  But that needs to =
be an entirely separate and purely informational draft.  In lieu of an =
IETF draft, you could instead publish the information as a blog post or =
web page.
>> Yes, why is this repeated so many times?
>> Let us instead complete the task to decide on information and syntax =
to convey between the endpoints.
>>=20
>> /Gunnar
>>>=20
>>>=20
>>=20
>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Fri Aug 19 08:27:51 2016
Return-Path: 
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 4CBD212D8CB for ; Fri, 19 Aug 2016 08:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
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 mg1VZCiI66D4 for ; Fri, 19 Aug 2016 08:27:45 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50082.outbound.protection.outlook.com [40.107.5.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FCD12D51F for ; Fri, 19 Aug 2016 08:27:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7ELw5nqCr4LvHLDmVpkFmFS9VW3UBou0fIeJI+6aqYk=; b=f+ciVnZLU5e8SrUbchD2Qskl/xUGpx7oXmZNq2A630tdcmyw34jVpEK0yMKTl3VS4kdm5LU+rUVbEmznYyF7QwOXzVBMBavNbq5rSlI6XAsFCfJ6bU3CFbA/+fdoyVZnPu0FxeZsksFeDfYmODfyhW/D/agFJvO/GXxkCbYLAuM=
Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2062.eurprd04.prod.outlook.com (10.166.141.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Fri, 19 Aug 2016 15:27:40 +0000
Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0587.005; Fri, 19 Aug 2016 15:27:40 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
Thread-Index: AQHR+Y9k1VVQ6qprEkOHEC0rLOyBb6BP4MEAgACIk4A=
Date: Fri, 19 Aug 2016 15:27:40 +0000
Message-ID: 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>   <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>  <5765d3d8-04fe-b2f5-19bb-5628dd6c57d2@omnitor.se> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3124)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [51.6.137.233]
x-ms-office365-filtering-correlation-id: e4c4a3cd-9f09-4ec4-3f39-08d3c8455b85
x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2062; 6:kriDwp9pXlK7/rRkktA1/ayEoi7hiesomE4mLOYDKNMGlmhlljHcJPb7rHwKZPBtqBrFZBsnTpYqXQzh2LWAyPueSt3YU0YRdq2U3AQhHz61AlTCeP9HNsaD6+/2qgUDMN+VfLlqAj9LpJHPDmUYfWZGT7qvTUueC2gVqQBE7ktJt1au49dDjFmZ1fDMpmcJvVgaAzrkpIWa1uXvNJvCegdXz5R0IRbvEFBIPNYKmfkKUaTyfEMA1eSPMryqTQQ9ZzaMEkKs01Di4G4VXP15apzmR5s8RPk1GbNnY8Wrqb0=; 5:M4y22tGfoBxsoA698lyROhOefFbNmVAyBWDA0Fx4RViMo1GLESh8HssMyYGETxn/xnackzM5hG+qUM1brzsKyRhGurtgVoakgkO/OPwHNnJgJAm0UtgyV5wB4DIxMkquAJH7l4Z0dU4GUD9LV/GMFQ==; 24:0yffsPwelrsmUsefV2Lx/dJW5O+CkCZzRQ4qGO8YxgS0Kiup6ztPx7GosVH7d67+XSd9jIBD4dvd7Y9q+hxlZDvnyybnWo4/B9iMgXaXtMk=; 7:UMdSSi3CyVN0DoAk22cvprLZndimGt/oj+ImxfaadskpUt86z5a8dtGqOjwg03VNjRFp/SDydkgZYhm+ObmrvNBetme948k6NYaGjv7pf8jRMFH4l7vUnUeSiuBrhAaFZaP1TUbuzhaJ7DtoXpn+uSGh2IBspPk72dg/n7UNsfWmRr5MUlBZWj6JGwGRwRrSneHIK1FPDq9qLFJjdqtHg7/iYCs4cXvJD4RBj2xQMqZOXDkhc0MC3jICHav4GmZF
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2062;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);  SRVR:VI1PR0401MB2062; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2062; 
x-forefront-prvs: 0039C6E5C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(189002)(377424004)(377454003)(199003)(24454002)(57306001)(66066001)(36756003)(92566002)(3280700002)(5890100001)(7736002)(11100500001)(7846002)(68736007)(2501003)(86362001)(450100001)(19580395003)(586003)(76176999)(50226002)(8676002)(3846002)(10400500002)(102836003)(81156014)(50986999)(8936002)(77096005)(6116002)(16236675004)(83716003)(81166006)(1730700003)(2906002)(3660700001)(2900100001)(101416001)(230783001)(82746002)(2351001)(5002640100001)(105586002)(87936001)(2950100001)(106116001)(93886004)(107886002)(19580405001)(106356001)(33656002)(189998001)(110136002)(97736004)(15975445007)(122556002)(5640700001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2062; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C10C1EFFF8D14C57B196361FDDF11321gsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2016 15:27:40.2779 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2062
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 51.6.137.233
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: VI1PR0401MB2062.eurprd04.prod.outlook.com
Archived-At: 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 15:27:49 -0000

--_000_C10C1EFFF8D14C57B196361FDDF11321gsmacom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi all,

The chairs (myself and Bernard) have discussed this item and I wish to reit=
erate the same point we have made at many stages:

This work is valuable for future work, not for the current drafts. Tickets =
related to these topics will be marked "future" and will not be resolved wi=
thin these documents but for future work.

This is delaying our work now so I suggest we close this discussion and re-=
open once we have pushed these documents through the RFC process.

Thanks!

Natasha


Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nroon=
ey@gsm.org


On 19 Aug 2016, at 08:18, Gunnar Hellstr=F6m > wrote:

It is amazing that we have not yet been able to solve the need for preferen=
ce indication independent of media.

We have been discussing it for 40 months (!), the surrounding standards req=
uiring it have defined that they need the function but cannot go on to deta=
il stage 3 of how to use our specification for this need.

With the current draft I can specify that I prefer to speak English but can=
 also with lower preference accept to speak French.

But I cannot specify that I prefer to sign BSL (British Sign Language) but =
can also with lower preference accept to read and write English. I do not s=
ee any logic in making that difference. It is just an incomplete specificat=
ion. And, since the examples about routing and setting up calls are preferr=
ed in this discussion, I can take a simple example from when this indicatio=
n is useful:

We have directives in force in Europe saying that all shall be equally well=
 taken care of by emergency services.

1. Person A prefers to use written English but knows BSL. (BSL is included =
in the capability indication so that calls with friends can be held in BSL =
without any relay service coming into the call)

2. Person B prefers BSL but can accept to use written English. (Written Eng=
lish is included in the capability indication so that calls with hearing pe=
ople with text capability can be held in text without a relay service comin=
g into the call )

3. An emergency service has a small group of people who communicate well in=
 BSL and other call-takers who speak and type English.

4. When user B calls emergency service, the call should be routed to the sm=
all group knowing sign language well and the call should start in BSL.

5. When user A calls emergency service, the call should be routed to the ge=
neral call-takers who have text and spoken capabilities.

6. With a method for preference indication between written English and BSL,=
 the ESInet can do the routing and send each call to the group most suited =
to take it.

7. Without a method for distinguishing the priorities between the two users=
, there is no way to route the calls to appropriate call-takers.

Many other similar examples can be made, from emergency calling as well as =
everyday calling.
So let us solve this need in the draft. I have proposed about 4 notations, =
with gradually reduced functionality, but still capable of solving the most=
 apparent needs. They are depending on what syntax we take for the attribut=
es, so let us try to decide on both the attribute syntax and the most favou=
red modality indication syntax together.

/Gunnar


Den 2016-08-18 kl. 22:30, skrev Gunnar Hellstr=F6m:
Den 2016-08-18 kl. 18:54, skrev Randall Gellens:

At 8:26 AM +0200 8/18/16, Gunnar Hellstr=F6m wrote:

Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
At 3:22 PM +0200 8/17/16, Gunnar Hellstr=F6m wrote:

  In order for the call to complete successfully you then need to know that=
 English both ways was selected, so that you start talking English in your =
answer. It would be a failure of our intentions if you only got a connected=
 indication and needed to start asking me what language I prefer.

Both endpoints know what was set up (English audio in your example).  What =
the endpoints do with this knowledge, including if and how they communicate=
 it to the user, is out of scope.

Yes, agreed. So our task in this draft is to describe the mechanism that en=
able the endpoints to have the information needed for a successful and smoo=
th start of the call =3D greeting from the called party in the most appropr=
iate language and modality.

No, the task is to enable the endpoints to set up the media.
This is not about setting up media. It is about conveying info to the endpo=
ints about what language to fill the media connections with. We have said m=
any times that media included in the offer are wanted anyway even if they a=
re not used for language.
The role for what we do for language is similar to what RFC 4796 The SDP Co=
ntents Attribute does for content types. It provides additional information=
 about the media to both endpoints.
In our case the information provided shall be sufficient for starting the c=
all in an appropriate language and modality. We do not say how the result o=
f the negotiation is provided to the "language generating entity", we just =
convey it to the endpoint ( or terminal or UA or client, whatever we want t=
o call it ) but the information needs to be sufficient to give most cases p=
roper base for the decision.
 What they do then is up to them.  You might want to write an "advice to im=
plementers" draft that provides information and suggestions to implementers=
 as to how to have a successful call.  But that needs to be an entirely sep=
arate and purely informational draft.  In lieu of an IETF draft, you could =
instead publish the information as a blog post or web page.
Yes, why is this repeated so many times?
Let us instead complete the task to decide on information and syntax to con=
vey between the endpoints.

/Gunnar




--
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


This email and its attachments are intended for the above named only and ma=
y be confidential. If they have come to you in error you must take no actio=
n based on them, nor must you copy or show them to anyone; please reply to =
this email or call +44 207 356 0600 and highlight the error.

--_000_C10C1EFFF8D14C57B196361FDDF11321gsmacom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Hi all, 






The chairs (myself and Bernard) have discussed this item an=
d I wish to reiterate the same point we have made at many stages:







This work is valuable for future work, not for the current =
drafts. Tickets related to these topics will be marked "future" a=
nd will not be resolved within these documents but for future work.







This is delaying our work now so I suggest we close this di=
scussion and re-open once we have pushed these documents through the RFC pr=
ocess.







Thanks!















Natasha





Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 77=
30 219 765 | @thisNatasha | Skype: nrooney@gsm.org




















On 19 Aug 2016, at 08:18, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se=
> wrote:






It is amazing that we have not yet been able to solve the n=
eed for preference indication independent of media.



We have been discussing it for 40 months (!), the surrounding standards req=
uiring it have defined that they need the function but cannot go on to deta=
il stage 3 of how to use our specification for this need.



With the current draft I can specify that I prefer to speak English but can=
 also with lower preference accept to speak French.



But I cannot specify that I prefer to sign BSL (British Sign Language) but =
can also with lower preference accept to read and write English. I do not s=
ee any logic in making that difference. It is just an incomplete specificat=
ion. And, since the examples about
 routing and setting up calls are preferred in this discussion, I can take =
a simple example from when this indication is useful:



We have directives in force in Europe saying that all shall be equally well=
 taken care of by emergency services.



1. Person A prefers to use written English but knows BSL. (BSL is included =
in the capability indication so that calls with friends can be held in BSL =
without any relay service coming into the call)



2. Person B prefers BSL but can accept to use written English. (Written Eng=
lish is included in the capability indication so that calls with hearing pe=
ople with text capability can be held in text without a relay service comin=
g into the call )



3. An emergency service has a small group of people who communicate well in=
 BSL and other call-takers who speak and type English.



4. When user B calls emergency service, the call should be routed to the sm=
all group knowing sign language well and the call should start in BSL.



5. When user A calls emergency service, the call should be routed to the ge=
neral call-takers who have text and spoken capabilities.



6. With a method for preference indication between written English and BSL,=
 the ESInet can do the routing and send each call to the group most suited =
to take it.



7. Without a method for distinguishing the priorities between the two users=
, there is no way to route the calls to appropriate call-takers.



Many other similar examples can be made, from emergency calling as well as =
everyday calling.

So let us solve this need in the draft. I have proposed about 4 notations, =
with gradually reduced functionality, but still capable of solving the most=
 apparent needs. They are depending on what syntax we take for the attribut=
es, so let us try to decide on both
 the attribute syntax and the most favoured modality indication syntax toge=
ther.



/Gunnar





Den 2016-08-18 kl. 22:30, skrev Gunnar Hellstr=F6m:


Den 2016-08-18 kl. 18:54, skrev Randal=
l Gellens:




At 8:26 AM +0200 8/18/16, Gunnar H=
ellstr=F6m wrote:




Den 2016-08-18 kl. 06:28, skrev Randal=
l Gellens:


At 3:22 PM +0200 8/17/16, Gunnar H=
ellstr=F6m wrote:




  In order for the call to c=
omplete successfully you then need to know that English both ways was selec=
ted, so that you start talking English in your answer. It would be a failur=
e of our intentions if you only got a connected
 indication and needed to start asking me what language I prefer.





Both endpoints know what was set up (English audio in your example).  =
What the endpoints do with this knowledge, including if and how they commun=
icate it to the user, is out of scope.





Yes, agreed. So our task in this draft is to describe the mechanism that en=
able the endpoints to have the information needed for a successful and smoo=
th start of the call =3D greeting from the called party in the most appropr=
iate language and modality.





No, the task is to enable the endpoints to set up the media.



This is not about setting up media. It is about conveying info to the endpo=
ints about what language to fill the media connections with. We have said m=
any times that media included in the offer are wanted anyway even if they a=
re not used for language.

The role for what we do for language is similar to what RFC 4796 The SDP Co=
ntents Attribute does for content types. It provides additional information=
 about the media to both endpoints.

In our case the information provided shall be sufficient for starting the c=
all in an appropriate language and modality. We do not say how the result o=
f the negotiation is provided to the "language generating entity"=
, we just convey it to the endpoint ( or terminal
 or UA or client, whatever we want to call it ) but the information needs t=
o be sufficient to give most cases proper base for the decision.


 What they do then is up to them.=
  You might want to write an "advice to implementers" draft =
that provides information and suggestions to implementers as to how to have=
 a successful call.  But that needs to be an entirely separate
 and purely informational draft.  In lieu of an IETF draft, you could =
instead publish the information as a blog post or web page.



Yes, why is this repeated so many times?

Let us instead complete the task to decide on information and syntax to con=
vey between the endpoints.



/Gunnar














-- 

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

Gunnar Hellstr=F6m

Omnitor

gunnar.hellstrom@=
omnitor.se

+46 708 204 288



_______________________________________________

SLIM mailing list

SLIM@ietf.org

https://www.ietf.org/mailman/listinfo/slim














This
 email and its attachments are intended for the above named only and may be=
 confidential. If they have come to you in error you must take no action ba=
sed on them, nor must you copy or show them to anyone; please reply to this=
 email or call +44 207 356 0600
 and highlight the error. 




--_000_C10C1EFFF8D14C57B196361FDDF11321gsmacom_--


From nobody Fri Aug 19 08:29:17 2016
Return-Path: 
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 EF0A912DB9F for ; Fri, 19 Aug 2016 08:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
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 pqjCP1TIaosY for ; Fri, 19 Aug 2016 08:29:12 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0086.outbound.protection.outlook.com [104.47.0.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD0F12DBA1 for ; Fri, 19 Aug 2016 08:28:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x6oRKU2jNx8Y7VCCnOowxqOZ6hMWpzmvFpDYQ0sXyeU=; b=jE41NU5f4q3qgnGGXB4GxNM6p1SeEddHLjIWsc+y4Hp8+gJUu0Km5nAGfM6mwjKKvi4EPt0RUbwbq1am1W8pdTyNGRuuEYmTEz2eRLZNamtoWLM9TwBTUPCsNIN+JmZSuBrADRB2ZQiA991Q1wOqJhDTqVOzJR3Lo0BFA0f8xKY=
Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2063.eurprd04.prod.outlook.com (10.166.141.137) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Fri, 19 Aug 2016 15:28:25 +0000
Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0587.005; Fri, 19 Aug 2016 15:28:25 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: Vacation
Thread-Index: AQHR+i5TsusE6MqecUCEX6TD7haTfw==
Date: Fri, 19 Aug 2016 15:28:25 +0000
Message-ID: <701FCC65-7FA3-47EA-B092-FA961E840CFE@gsma.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3124)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [51.6.137.233]
x-ms-office365-filtering-correlation-id: 0d2c4718-aec0-497b-1cc4-08d3c8457661
x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2063; 6:gIF2iUobqmVAJLfc7YnCcvSRhq12BP+aHx8d6pcCTEcIoP7t7CCB+nAdjW30kXUlL2bw4ctJGv6XRDmmCwecHYvsq1o+dYUIfC7B5jWoMZX57Xu8VWkxSVIUqxdEDQkHV9keOQw2OAr8RKsZDvO5X7LDNFgRQG/hu/rNVAKOxLPHq/5z0abB9C4B5TS7EEfI1mMF9T1Bki5dr3HRRLOWgEohNCh4Dienz4S95rprl91uLQZuKWYTeCF095O63P9qUXITNSoOlFyRI3Q4VlOxbAE833NnYyvOP1n+yCbAHgo=; 5:371q4E2BE2axMkyAIFL3EwRT5PmDQbKIorKEu7M2l6GMFnf8VNkg1LKp4V79O+MWwW/Qgbp7o6cgZlSnwGu6lnWvWRRkGxgAT1PGSna+BDQ0fSKP0lZeYgUaB+ySRksP75m94EhWx+/GZ8XBM89ZmA==; 24:7E0PkTilSL9ZRbZIT4P4HdvvDTlC13En29A8Ay+TfXEV+7UO+MInrcjS/nTUwvx5wcr4hxWY2kk8Q5T811d/7UXHOEHTEPe1KYnRuSlrMKQ=; 7:chPHTKIeCdAfgo8HNnG66/jdqaul5AW2ZyfXqcoZvSVSEYh37vIR3C74r7Qg5qs8TkKwUjrzHv3uRaKk8f/eMb9zzXQ1PrdazTwnVjzNfrzvB+TgO4yEK4fahvXuUk0EjS+aPmZB0eqE+8JzpGWfRC4+wFVe1g6Hpf6Xk+qlqAo0Yc9s1vj7SCwX9BNaDEPLtebN8kzfrEthS4Sule9GaiugcCbCewaVjETsxcQ17uf2mqTfvhNdKJrzOUY6Dm/h
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2063;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);  SRVR:VI1PR0401MB2063; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2063; 
x-forefront-prvs: 0039C6E5C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(55674003)(189002)(199003)(82746002)(3846002)(102836003)(221733001)(5890100001)(19580395003)(11100500001)(2900100001)(33656002)(5002640100001)(19580405001)(450100001)(66066001)(7846002)(81156014)(1730700003)(83716003)(10400500002)(68736007)(6116002)(2351001)(106356001)(5640700001)(77096005)(8676002)(586003)(8936002)(81166006)(7736002)(229853001)(110136002)(107886002)(50226002)(3480700004)(189998001)(101416001)(97736004)(50986999)(122556002)(36756003)(2906002)(16236675004)(106116001)(2501003)(57306001)(86362001)(3280700002)(3660700001)(92566002)(105586002)(87936001)(7116003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2063; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_701FCC657FA347EAB092FA961E840CFEgsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2016 15:28:25.2305 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2063
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 51.6.137.233
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: VI1PR0401MB2063.eurprd04.prod.outlook.com
Archived-At: 
Subject: [Slim] Vacation
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 15:29:15 -0000

--_000_701FCC657FA347EAB092FA961E840CFEgsmacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am away now until Sept 5th. In the meantime Bernard will be chairing alon=
e and working through the open tickets. I hope you all have a good rest of =
the summer period!

Natasha


Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nroon=
ey@gsm.org



This email and its attachments are intended for the above named only and ma=
y be confidential. If they have come to you in error you must take no actio=
n based on them, nor must you copy or show them to anyone; please reply to =
this email or call +44 207 356 0600 and highlight the error.

--_000_701FCC657FA347EAB092FA961E840CFEgsmacom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <85D3AAD18BE9814EBAB01253B7B5F2D2@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






I am away now until Sept 5th. In the meantime Bernard will be chairing alon=
e and working through the open tickets. I hope you all have a good rest of =
the summer period!












Natasha





Natasha Rooney | Internet Engineering Director | GSMA | nrooney@gsma.com | +44 (0) 77=
30 219 765 | @thisNatasha | Skype: nrooney@gsm.org
















This
 email and its attachments are intended for the above named only and may be=
 confidential. If they have come to you in error you must take no action ba=
sed on them, nor must you copy or show them to anyone; please reply to this=
 email or call +44 207 356 0600
 and highlight the error. 




--_000_701FCC657FA347EAB092FA961E840CFEgsmacom_--


From nobody Fri Aug 19 08:58:15 2016
Return-Path: 
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 2785C12DBAE for ; Fri, 19 Aug 2016 08:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 Z8aDk7auXVi9 for ; Fri, 19 Aug 2016 08:58:09 -0700 (PDT)
Received: from bin-vsp-out-02.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 3140C12DBA3 for ; Fri, 19 Aug 2016 08:57:49 -0700 (PDT)
X-Halon-ID: a8f97530-6625-11e6-b846-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 19 Aug 2016 17:57:41 +0200 (CEST)
To: Natasha Rooney , "slim@ietf.org" 
References: <067.2c10de186e2d223a6fb817b1e45b7373@tools.ietf.org> <082.14433c4436147c3623bf5eb155bb64a8@tools.ietf.org> <64BAB53A-B564-4599-B19F-57B76D103ED7@brianrosen.net>   <25c701df-3416-0ff6-4688-257231b3f3df@omnitor.se>  <5765d3d8-04fe-b2f5-19bb-5628dd6c57d2@omnitor.se>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Fri, 19 Aug 2016 17:57:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------62DEA152DAAC159B6E864127"
Archived-At: 
Subject: Re: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 15:58:13 -0000

This is a multi-part message in MIME format.
--------------62DEA152DAAC159B6E864127
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Natasha,

Please note that Issue #6 was not related to the closed topic, and that 
its latest comment had a proposal for less drastic changes than the 
original one. So it should stay open and be valid for regular 
discussions of rewording proposals for the draft.

Have a nice vacation,

/Gunnar

Den 2016-08-19 kl. 17:27, skrev Natasha Rooney:
> Hi all,
>
> The chairs (myself and Bernard) have discussed this item and I wish to 
> reiterate the same point we have made at many stages:
>
> This work is valuable for future work, not for the current drafts. 
> Tickets related to these topics will be marked "future" and will not 
> be resolved within these documents but for future work.
>
> This is delaying our work now so I suggest we close this discussion 
> and re-open once we have pushed these documents through the RFC process.
>
> Thanks!
>
> Natasha
>
>
> Natasha Rooney | Internet Engineering Director | GSMA | 
> nrooney@gsma.com  | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: nrooney@gsm.org 
>
>
>> On 19 Aug 2016, at 08:18, Gunnar Hellström 
>> > wrote:
>>
>> It is amazing that we have not yet been able to solve the need for 
>> preference indication independent of media.
>>
>> We have been discussing it for 40 months (!), the surrounding 
>> standards requiring it have defined that they need the function but 
>> cannot go on to detail stage 3 of how to use our specification for 
>> this need.
>>
>> With the current draft I can specify that I prefer to speak English 
>> but can also with lower preference accept to speak French.
>>
>> But I cannot specify that I prefer to sign BSL (British Sign 
>> Language) but can also with lower preference accept to read and write 
>> English. I do not see any logic in making that difference. It is just 
>> an incomplete specification. And, since the examples about routing 
>> and setting up calls are preferred in this discussion, I can take a 
>> simple example from when this indication is useful:
>>
>> We have directives in force in Europe saying that all shall be 
>> equally well taken care of by emergency services.
>>
>> 1. Person A prefers to use written English but knows BSL. (BSL is 
>> included in the capability indication so that calls with friends can 
>> be held in BSL without any relay service coming into the call)
>>
>> 2. Person B prefers BSL but can accept to use written English. 
>> (Written English is included in the capability indication so that 
>> calls with hearing people with text capability can be held in text 
>> without a relay service coming into the call )
>>
>> 3. An emergency service has a small group of people who communicate 
>> well in BSL and other call-takers who speak and type English.
>>
>> 4. When user B calls emergency service, the call should be routed to 
>> the small group knowing sign language well and the call should start 
>> in BSL.
>>
>> 5. When user A calls emergency service, the call should be routed to 
>> the general call-takers who have text and spoken capabilities.
>>
>> 6. With a method for preference indication between written English 
>> and BSL, the ESInet can do the routing and send each call to the 
>> group most suited to take it.
>>
>> 7. Without a method for distinguishing the priorities between the two 
>> users, there is no way to route the calls to appropriate call-takers.
>>
>> Many other similar examples can be made, from emergency calling as 
>> well as everyday calling.
>> So let us solve this need in the draft. I have proposed about 4 
>> notations, with gradually reduced functionality, but still capable of 
>> solving the most apparent needs. They are depending on what syntax we 
>> take for the attributes, so let us try to decide on both the 
>> attribute syntax and the most favoured modality indication syntax 
>> together.
>>
>> /Gunnar
>>
>>
>> Den 2016-08-18 kl. 22:30, skrev Gunnar Hellström:
>>> Den 2016-08-18 kl. 18:54, skrev Randall Gellens:
>>>
>>>> At 8:26 AM +0200 8/18/16, Gunnar Hellström wrote:
>>>>
>>>>> Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
>>>>>> At 3:22 PM +0200 8/17/16, Gunnar Hellström wrote:
>>>>>>
>>>>>>>   In order for the call to complete successfully you then need 
>>>>>>> to know that English both ways was selected, so that you start 
>>>>>>> talking English in your answer. It would be a failure of our 
>>>>>>> intentions if you only got a connected indication and needed to 
>>>>>>> start asking me what language I prefer.
>>>>>>
>>>>>> Both endpoints know what was set up (English audio in your 
>>>>>> example).  What the endpoints do with this knowledge, including 
>>>>>> if and how they communicate it to the user, is out of scope.
>>>>>>
>>>>> Yes, agreed. So our task in this draft is to describe the 
>>>>> mechanism that enable the endpoints to have the information needed 
>>>>> for a successful and smooth start of the call = greeting from the 
>>>>> called party in the most appropriate language and modality.
>>>>
>>>> No, the task is to enable the endpoints to set up the media.
>>> This is not about setting up media. It is about conveying info to 
>>> the endpoints about what language to fill the media connections 
>>> with. We have said many times that media included in the offer are 
>>> wanted anyway even if they are not used for language.
>>> The role for what we do for language is similar to what RFC 4796 The 
>>> SDP Contents Attribute does for content types. It provides 
>>> additional information about the media to both endpoints.
>>> In our case the information provided shall be sufficient for 
>>> starting the call in an appropriate language and modality. We do not 
>>> say how the result of the negotiation is provided to the "language 
>>> generating entity", we just convey it to the endpoint ( or terminal 
>>> or UA or client, whatever we want to call it ) but the information 
>>> needs to be sufficient to give most cases proper base for the decision.
>>>>  What they do then is up to them.  You might want to write an 
>>>> "advice to implementers" draft that provides information and 
>>>> suggestions to implementers as to how to have a successful call. 
>>>>  But that needs to be an entirely separate and purely informational 
>>>> draft.  In lieu of an IETF draft, you could instead publish the 
>>>> information as a blog post or web page.
>>> Yes, why is this repeated so many times?
>>> Let us instead complete the task to decide on information and syntax 
>>> to convey between the endpoints.
>>>
>>> /Gunnar
>>>>
>>>>
>>>
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se 
>> +46 708 204 288
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>
> This email and its attachments are intended for the above named only 
> and may be confidential. If they have come to you in error you must 
> take no action based on them, nor must you copy or show them to 
> anyone; please reply to this email or call +44 207 356 0600 and 
> highlight the error.
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


--------------62DEA152DAAC159B6E864127
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Natasha,

    
Please note that Issue #6 was not related to the closed topic,
      and that its latest comment had a proposal for less drastic
      changes than the original one. So it should stay open and be valid
      for regular discussions of rewording proposals for the draft.

    
Have a nice vacation,

    
/Gunnar

    

    
Den 2016-08-19 kl. 17:27, skrev Natasha
      Rooney:

    

    

      
      Hi all, 
      


      

      
The chairs (myself and Bernard) have discussed this
        item and I wish to reiterate the same point we have made at many
        stages:

      


      

      
This work is valuable for future work, not for the
        current drafts. Tickets related to these topics will be marked
        "future" and will not be resolved within these documents but for
        future work.

      


      

      
This is delaying our work now so I suggest we close
        this discussion and re-open once we have pushed these documents
        through the RFC process.

      


      

      
Thanks!

      

        

          

            

              

                

                  

                  Natasha

                  

                  

                  Natasha Rooney | Internet Engineering Director | GSMA
                  | nrooney@gsma.com |
                  +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org

                  

                

              

            

          

        

        

        

          

            
On 19 Aug 2016, at 08:18, Gunnar Hellström
              <gunnar.hellstrom@omnitor.se>
              wrote:

            

            

              
It is amazing that we have not yet been able
                to solve the need for preference indication independent
                of media.

                

                We have been discussing it for 40 months (!), the
                surrounding standards requiring it have defined that
                they need the function but cannot go on to detail stage
                3 of how to use our specification for this need.

                

                With the current draft I can specify that I prefer to
                speak English but can also with lower preference accept
                to speak French.

                

                But I cannot specify that I prefer to sign BSL (British
                Sign Language) but can also with lower preference accept
                to read and write English. I do not see any logic in
                making that difference. It is just an incomplete
                specification. And, since the examples about routing and
                setting up calls are preferred in this discussion, I can
                take a simple example from when this indication is
                useful:

                

                We have directives in force in Europe saying that all
                shall be equally well taken care of by emergency
                services.

                

                1. Person A prefers to use written English but knows
                BSL. (BSL is included in the capability indication so
                that calls with friends can be held in BSL without any
                relay service coming into the call)

                

                2. Person B prefers BSL but can accept to use written
                English. (Written English is included in the capability
                indication so that calls with hearing people with text
                capability can be held in text without a relay service
                coming into the call )

                

                3. An emergency service has a small group of people who
                communicate well in BSL and other call-takers who speak
                and type English.

                

                4. When user B calls emergency service, the call should
                be routed to the small group knowing sign language well
                and the call should start in BSL.

                

                5. When user A calls emergency service, the call should
                be routed to the general call-takers who have text and
                spoken capabilities.

                

                6. With a method for preference indication between
                written English and BSL, the ESInet can do the routing
                and send each call to the group most suited to take it.

                

                7. Without a method for distinguishing the priorities
                between the two users, there is no way to route the
                calls to appropriate call-takers.

                

                Many other similar examples can be made, from emergency
                calling as well as everyday calling.

                So let us solve this need in the draft. I have proposed
                about 4 notations, with gradually reduced functionality,
                but still capable of solving the most apparent needs.
                They are depending on what syntax we take for the
                attributes, so let us try to decide on both the
                attribute syntax and the most favoured modality
                indication syntax together.

                

                /Gunnar

                

                

                Den 2016-08-18 kl. 22:30, skrev Gunnar Hellström:

                
Den 2016-08-18 kl.
                  18:54, skrev Randall Gellens:

                  

                  
At 8:26 AM +0200
                    8/18/16, Gunnar Hellström wrote:

                    

                    
Den 2016-08-18 kl.
                      06:28, skrev Randall Gellens:

                      
At 3:22 PM +0200
                        8/17/16, Gunnar Hellström wrote:

                        

                        
  In order for
                          the call to complete successfully you then
                          need to know that English both ways was
                          selected, so that you start talking English in
                          your answer. It would be a failure of our
                          intentions if you only got a connected
                          indication and needed to start asking me what
                          language I prefer.

                        

                        

                        Both endpoints know what was set up (English
                        audio in your example).  What the endpoints do
                        with this knowledge, including if and how they
                        communicate it to the user, is out of scope.

                        

                      

                      Yes, agreed. So our task in this draft is to
                      describe the mechanism that enable the endpoints
                      to have the information needed for a successful
                      and smooth start of the call = greeting from the
                      called party in the most appropriate language and
                      modality.

                    

                    

                    No, the task is to enable the endpoints to set up
                    the media.

                  

                  This is not about setting up media. It is about
                  conveying info to the endpoints about what language to
                  fill the media connections with. We have said many
                  times that media included in the offer are wanted
                  anyway even if they are not used for language.

                  The role for what we do for language is similar to
                  what RFC 4796 The SDP Contents Attribute does for
                  content types. It provides additional information
                  about the media to both endpoints.

                  In our case the information provided shall be
                  sufficient for starting the call in an appropriate
                  language and modality. We do not say how the result of
                  the negotiation is provided to the "language
                  generating entity", we just convey it to the endpoint
                  ( or terminal or UA or client, whatever we want to
                  call it ) but the information needs to be sufficient
                  to give most cases proper base for the decision.

                  
 What they do then is
                    up to them.  You might want to write an "advice to
                    implementers" draft that provides information and
                    suggestions to implementers as to how to have a
                    successful call.  But that needs to be an entirely
                    separate and purely informational draft.  In lieu of
                    an IETF draft, you could instead publish the
                    information as a blog post or web page.

                  

                  Yes, why is this repeated so many times?

                  Let us instead complete the task to decide on
                  information and syntax to convey between the
                  endpoints.

                  

                  /Gunnar

                  


                    

                  

                  

                

                

                -- 

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

                Gunnar Hellström

                Omnitor

                gunnar.hellstrom@omnitor.se

                +46 708 204 288

                

                _______________________________________________

                SLIM mailing list

                SLIM@ietf.org

                https://www.ietf.org/mailman/listinfo/slim

              

            

          

        

        

      

      
This email and its
          attachments are intended for the above named only and may be
          confidential. If they have come to you in error you must take
          no action based on them, nor must you copy or show them to
          anyone; please reply to this email or call +44 207 356 0600
          and highlight the error. 

      

      

      

      
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


    

    

    
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  


--------------62DEA152DAAC159B6E864127--


From nobody Mon Aug 29 19:44:53 2016
Return-Path: 
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 9620112B054 for ; Mon, 29 Aug 2016 19:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 me07jVFIW6aG for ; Mon, 29 Aug 2016 19:44:49 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D948912B00E for ; Mon, 29 Aug 2016 19:44:48 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id i32so10392192uai.2 for ; Mon, 29 Aug 2016 19:44:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=hojTpgAfhulFP1fX8Tz/0ZxmkJPlIJb33i70kU9nR2E=; b=lbsy9n36+9RgWjsASlsl1uT4O98ILbNGx7ODA+1dBdF8YYEGTsMxn8QuUxp4CXJMxe xsJhdADLV72ozSQmlNe/pi+XlkoALxhxcm+vAxenBRDy0XZaOF+ln0wEyUcanq6z1VOC DDHZQAjI3bvE9s1p+lP/42Q3Zr0rXbGeCrpOJVSFgITNHzJNWE+RisIr3R/WGvtH02pk vD1qH/Jy+OYgRObagF5sfRa4vfRhaLrKru4YJqgOc+SMlIN+H56iqOE+ackNLHD6Bd92 Ht4ayTfwHBK0tG8Dkco4GDVICy91z0MjYU+xBjJzBAO54McPfMnETHa/beAw5EXJNV/4 pQOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hojTpgAfhulFP1fX8Tz/0ZxmkJPlIJb33i70kU9nR2E=; b=E0OZ8apPgi/O73jKROzopZ1Wdmq57o396V0Ou2eOjmjmt8hovrHzp0UKE9qxNjZy/6 pzS7hAlXTsV+tasn3ag5jCeKOQEUj+8b7fZjkuUEvWw1l+mkZ4nfP6NZ7JhVsF/FdmY1 l+nusfh7SqsvUgib5i/LTMCi/rX4vV7vRRUPO+yby7vEJVN5u5PiYEOKzHDRiBLhYNm2 /7i+L0kl+LYBV8/DNVJGTUvhq8z4IH0LCYzpQSbEHb52qG79nZA3Era8fV48n4Meyf8N eZtDeq4QfzyOXcp7BtiMxe4O9Uul1TWNIQBcjrF5JpxVKKzfCt36LKGBiW9PW6h006L2 NNzQ==
X-Gm-Message-State: AE9vXwN2fEPKDLjcCeKDxQ46PvBlEikue8RkH1DuOeztgYjEdd3ptnizp/foNf6lN5Md51KILvZlqpWJ+QR7zA==
X-Received: by 10.31.227.196 with SMTP id a187mr806801vkh.89.1472525087707; Mon, 29 Aug 2016 19:44:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.2.135 with HTTP; Mon, 29 Aug 2016 19:44:46 -0700 (PDT)
Received: by 10.176.2.135 with HTTP; Mon, 29 Aug 2016 19:44:46 -0700 (PDT)
In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com>
References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com>
From: Bernard Aboba 
Date: Mon, 29 Aug 2016 19:44:46 -0700
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary=001a114e0198c6964b053b40f64d
Archived-At: 
Subject: [Slim] Fwd: NomCom 2016-2017: Call for Nominations
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 02:44:52 -0000

--001a114e0198c6964b053b40f64d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FYI.
---------- Forwarded message ----------
From: "NomCom Chair 2016" 
Date: Aug 29, 2016 1:52 PM
Subject: NomCom 2016-2017: Call for Nominations
To: "Working Group Chairs" 
Cc:

Please forward on to your Working Groups -

The 2016-17 Nominating Committee (Nomcom) is seeking nominations from
now until October 8, 2016. The open positions being considered by this
year's Nomcom can be found at the end of this email and also on this
year's Nomcom website:

https://datatracker.ietf.org/nomcom/2016/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2016 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2016/nominate/

  {Note that nominations made using the web tool require an ietf.org
   datatracker account. You can create a datatracker ietf.org account
   if you don't have one already by visiting the following URL:
   https://datatracker.ietf.org/accounts/create/ }

If you are unable to use the web form, nominations may instead be made
by email to nomcom-16@ietf.org. If using email, please include the word
"Nominate" in the Subject and indicate in the email who is being
nominated, their email address (to confirm acceptance of the
nomination), and the position for which you are making the nomination.
If you are nominating someone other than yourself, please tell us if
we may tell the nominee that you were the one who made the nomination.
If you wish to nominate someone via email for more than one position,
please use separate emails to do so.

Self-nomination is welcome!

Willing nominees will be asked to fill out a questionnaire
specific to the position for which they are nominated.  The questionnaires
will be available on September 2, 2016 and have a submission deadline of
October 13, 2016.

NomCom 2016-17 will follow the policy for "Open Disclosure of Willing
Nominees" described in BCP 10/RFC 7437.  As stated in RFC 7437: "The
list of nominees willing to be considered for positions under review
in the current Nomcom cycle is not confidential". Willing nominees for
each position will be listed in a publicly accessible way - anyone
with a datatracker account may access the lists.  Additionally, the
nomination form asks if we may share your own name with the
nominee. In all other ways, the confidentiality requirements of BCP10
remain in effect.  All feedback and all Nomcom deliberations will
remain confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the Nomcom
to tell the nominee that you were the one who made the
nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark th=
e field
we won=E2=80=99t tell.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
NomCom on or before October 8, 2016.

Please submit your nominations as early as possible for the sake of
your nominees. Note that nominations should not wait for management
permission, as it is easier to decline the nomination than put one in
late.

The Nomcom appoints individuals to fill the open slots on the IAOC,
the IAB, and the IESG. The list of people and posts whose terms end
with the March 2017 IETF meeting, and thus the positions for which
this Nomcom is responsible, follows:

IAOC

    Lou Berger

IAB

    Ralph Droms*
    Russ Housley*
    Robert Sparks
    Andrew Sullivan
    Dave Thaler*
    Suzanne Woolf

IESG

    Jari Arkko (GEN)*
    Deborah Brungard (RTG)
    Ben Campbell (ART)
    Spencer Dawkins (TSV)
    Stephen Farrell (SEC)*
    Joel Jaeggli (OPS)*
    Terry Manderson (INT)
    Alvaro Retana (RTG)

*- have indicated that they do not intend to accept a
renomination. This information is always up to date on
https://datatracker.ietf.org/nomcom/2016/

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF, and also, please consider accepting a nomination.  You'll
find extensive information about specific positions, developed by the
IAB, IESG, and IAOC, under individual tabs at:

  https://datatracker.ietf.org/nomcom/2016/requirements/

In addition to nominations, the Nomcom seeks community input on the
positions themselves.  We need and welcome the community's views and
input on the jobs within each organization. If you have ideas on the
positions' responsibilities (more, less, different), please let us
know.

Please send suggestions and feedback about this to nomcom-16@ietf.org.

Thank you for your help in identifying qualified nominees!

Lucy Lynch
Nomcom Chair 2016-17
nomcom-chair-2016@ietf.org
llynch@civil-tongue.net

--001a114e0198c6964b053b40f64d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


FYI. 


---------- Forwarded message ----------
From:=
 "NomCom Chair 2016" <nomcom-chair-2016@ietf.org>
Date: Aug 29, 2016 1:52 PM
S=
ubject: NomCom 2016-2017: Call for Nominations
To: "Working Group C=
hairs" <wgchairs@ietf.org&=
gt;
Cc: 

Please forward on to your Working G=
roups -



The 2016-17 Nominating Committee (Nomcom) is seeking nominations from

now until October 8, 2016. The open positions being considered by this

year's Nomcom can be found at the end of this email and also on this
year's Nomcom website:



https://datatracker.ietf.org/nomcom/2016/



Nominations may be made by selecting the Nominate link at the top of

the Nomcom 2016 home page, or by visiting the following URL:



https://datatracker.ietf.org/nomcom/2016/nomi=
nate/



=C2=A0 {Note that nominations made using the web tool require an ietf.org

=C2=A0 =C2=A0datatracker account. You can create a datatracker ietf.org account
=C2=A0 =C2=A0if you don't have one already by visiting the following UR=
L:

=C2=A0 =C2=A0https://datatracker.ietf.org/account=
s/create/ }



If you are unable to use the web form, nominations may instead be made

by email to nomcom-16@ietf.org. I=
f using email, please include the word

"Nominate" in the Subject and indicate in the email who is being<=
br>
nominated, their email address (to confirm acceptance of the

nomination), and the position for which you are making the nomination.

If you are nominating someone other than yourself, please tell us if

we may tell the nominee that you were the one who made the nomination.

If you wish to nominate someone via email for more than one position,

please use separate emails to do so.



Self-nomination is welcome!



Willing nominees will be asked to fill out a questionnaire

specific to the position for which they are nominated.=C2=A0 The questionna=
ires

will be available on September 2, 2016 and have a submission deadline of
October 13, 2016.



NomCom 2016-17 will follow the policy for "Open Disclosure of Willing<=
br>
Nominees" described in BCP 10/RFC 7437.=C2=A0 As stated in RFC 7437: &=
quot;The

list of nominees willing to be considered for positions under review

in the current Nomcom cycle is not confidential". Willing nominees for=


each position will be listed in a publicly accessible way - anyone

with a datatracker account may access the lists.=C2=A0 Additionally, the
nomination form asks if we may share your own name with the

nominee. In all other ways, the confidentiality requirements of BCP10

remain in effect.=C2=A0 All feedback and all Nomcom deliberations will

remain confidential and will not be disclosed.



There is a field on the form you can mark in order to allow the Nomcom

to tell the nominee that you were the one who made the

nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mar=
k the field

we won=E2=80=99t tell.



In order to ensure time to collect sufficient community feedback about

each of the willing nominees, nominations must be received by the

NomCom on or before October 8, 2016.



Please submit your nominations as early as possible for the sake of

your nominees. Note that nominations should not wait for management

permission, as it is easier to decline the nomination than put one in

late.



The Nomcom appoints individuals to fill the open slots on the IAOC,

the IAB, and the IESG. The list of people and posts whose terms end

with the March 2017 IETF meeting, and thus the positions for which

this Nomcom is responsible, follows:



IAOC



=C2=A0 =C2=A0 Lou Berger



IAB



=C2=A0 =C2=A0 Ralph Droms*

=C2=A0 =C2=A0 Russ Housley*

=C2=A0 =C2=A0 Robert Sparks

=C2=A0 =C2=A0 Andrew Sullivan

=C2=A0 =C2=A0 Dave Thaler*

=C2=A0 =C2=A0 Suzanne Woolf



IESG



=C2=A0 =C2=A0 Jari Arkko (GEN)*

=C2=A0 =C2=A0 Deborah Brungard (RTG)

=C2=A0 =C2=A0 Ben Campbell (ART)

=C2=A0 =C2=A0 Spencer Dawkins (TSV)

=C2=A0 =C2=A0 Stephen Farrell (SEC)*

=C2=A0 =C2=A0 Joel Jaeggli (OPS)*

=C2=A0 =C2=A0 Terry Manderson (INT)

=C2=A0 =C2=A0 Alvaro Retana (RTG)



*- have indicated that they do not intend to accept a

renomination. This information is always up to date on

https://datatracker.ietf.org/nomcom/2016/



Please be resourceful in identifying possible candidates for these

positions, as developing our talent is a very crucial requirement for

the IETF, and also, please consider accepting a nomination.=C2=A0 You'l=
l

find extensive information about specific positions, developed by the

IAB, IESG, and IAOC, under individual tabs at:



=C2=A0 https://datatracker.ietf.org/nomco=
m/2016/requirements/



In addition to nominations, the Nomcom seeks community input on the

positions themselves.=C2=A0 We need and welcome the community's views a=
nd

input on the jobs within each organization. If you have ideas on the

positions' responsibilities (more, less, different), please let us

know.



Please send suggestions and feedback about this to nomcom-16@ietf.org.



Thank you for your help in identifying qualified nominees!



Lucy Lynch

Nomcom Chair 2016-17

nomcom-chair-2016@ietf.org

llynch@civil-tongue.net






--001a114e0198c6964b053b40f64d--


From nobody Tue Aug 30 13:50:00 2016
Return-Path: 
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 70FB912D094 for ; Tue, 30 Aug 2016 13:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 zs6fp-1YNVUz for ; Tue, 30 Aug 2016 13:49:57 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA1712B034 for ; Tue, 30 Aug 2016 13:49:57 -0700 (PDT)
Received: from localhost ([::1]:48546 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bepyn-0002t0-5K; Tue, 30 Aug 2016 13:49:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "slim issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: rfc.nik.tomkinson@gmail.com
X-Trac-Project: slim
Date: Tue, 30 Aug 2016 20:49:56 -0000
X-URL: https://tools.ietf.org/slim/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/slim/trac/ticket/19#comment:3
Message-ID: <082.1d2b7aa670ce09ecb7b42f1d9d850bb8@tools.ietf.org>
References: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-Trac-Ticket-ID: 19
In-Reply-To: <067.517ab8278ea72dd9b86ffc2074a86fb1@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rfc.nik.tomkinson@gmail.com, slim@ietf.org
X-SA-Exim-Mail-From: trac+slim@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] [slim] #19 (multilangcontent): Use Media Type registration template
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 20:49:59 -0000

#19: Use Media Type registration template


Comment (by rfc.nik.tomkinson@gmail.com):

 Hi All,

 I am working on this template but I need some advice from anyone who knows
 this sort of this thing well and has experience in this area.

 My initial suggestion would be:

      Media Type name: multipart

      Media subtype name: multilingual

      Required parameters: boundary (defined in RFC2046)

      Optional parameters: N/A

      Encoding considerations: ?

      Security considerations: See the Security Considerations section in
 this document

      Interoperability considerations:
          Existing systems that do not treat unknown multipart subtypes
          as multipart/mixed may not correctly render a
          multipart/multilingual type.

      Published specification: This document

      Applications that use this media type:
          Mail Transfer Agents, Mail User Agents, spam detection,
          virus detection modules and message authentication modules.

      Additional information:

          Deprecated alias names for this type: N/A
          Magic number(s): N/A
          File extension(s): N/A
          Macintosh file type code(s): N/A

      Person & email address to contact for further information:
          Nik Tomkinson
          rfc.nik.tomkinson@gmail.com

          Nathaniel Borenstein
          nsb@mimecast.com

      Intended usage: Common



 But I am not sure about the encoding considerations because the IANA
 'Application for a Media Type' form at http://www.iana.org/form/media-
 types includes these options:
  - 7-bit text
  - 8-bit text (this media type may require encoding on transports not
 capable of handling 8-bit text)
  - binary (this media type may require encoding on transports not capable
 of handling binary)

 but it also refers to RFC 6838 §4.8
 which lists:
  - 7bit:  The content of the media type consists solely of CRLF-delimited
 7bit US-ASCII text.
  - 8bit:  The content of the media type consists solely of CRLF-delimited
 8bit text.
  - binary:  The content consists of an unrestricted sequence of octets.

 I have seen from examples of other registered MIME types that the wording
 is not always the same as above but, given that there is a registration
 form with strict definitions, I am at a bit of a loss which I should
 specify.

 Can anyone offer a suggestion?

 Thanks in advance,

 Nik.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rfc.nik.tomkinson@gmail.com        |  rfc.nik.tomkinson@gmail.com
     Type:  enhancement              |      Status:  assigned
 Priority:  major                    |   Milestone:
Component:  multilangcontent         |     Version:
 Severity:  In WG Last Call          |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
slim