From nobody Wed Jan 29 13:47:16 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6E7120026; Wed, 29 Jan 2020 13:47:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rum@ietf.org Message-ID: <158033443345.2803.14350232562292068648@ietfa.amsl.com> Date: Wed, 29 Jan 2020 13:47:13 -0800 Archived-At: Subject: [Rum] I-D Action: draft-ietf-rum-rue-02.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 21:47:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Relay User Machine WG of the IETF. Title : Interoperability Profile for Relay User Equipment Author : Brian Rosen Filename : draft-ietf-rum-rue-02.txt Pages : 28 Date : 2020-01-29 Abstract: Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other dead/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document describes the interface between a videophone and a provider. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rum-rue-02 https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-02 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 Jan 29 14:51:21 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBBF12002F for ; Wed, 29 Jan 2020 14:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 zDSEpepsg0Zc for ; Wed, 29 Jan 2020 14:51:17 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2084.outbound.protection.outlook.com [40.107.236.84]) (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 5E890120019 for ; Wed, 29 Jan 2020 14:51:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X7JLmX8RKs6xtC3EwUdlNGpiIuKIglAf+1SWx2AB5IYT8MJv/sSpj/MnwSWd7iYcO4DMF32FKKZUpbRPj7kctr1msxlYmf6uI0ruNbOeP1REQjnG9Q0KsbiTCRD5C4CCSIJc14fHkbjgm7IfPUghdmVIJcZJQsmPePgF1qP4hOoCbYSnhGkZTBMCxDmb7E4N/NccfySjhMrvJN7l4roNFGG7jRz5ZDcRUbRNyEIll+HWpOx5GYDS3yL4XNzB0blh9jeSRIOycCnfhFzWZC8UlReBCjbpbfb2xEK12A4i74qd1CnJcm9+1Xup9SL+YzjyGSylOcIr9RTmWlJex4H3og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lgOB1tMmxDt7Vh6zexkxbNfm8YqJy0OQRgjBYN7c08Q=; b=c4lxkc/usZK/asmtabbnU2Am4+nYSWwm0v2d3N635o1p1oQob9BbGvC7PiWKTWfVaad+eD8FNKZZwlPAqHO3Qnib6duwEnOlEn3EfSZ6LyiO7SsBF+nsUVSJ0VnwKeFBa0G0S5jsPGog2SYtX9H2/EYhD6wBA2WS10+YO7xPQ2ai4QXhyw4FL7Ur4yk5XVLzmN8juq1cW+CSxNNAQ8LxCdqDE42If7/NxGayT3eAauKZFSINgFd2CitKJfnOIMf3byM1ytNeg0n8+KPdduihqiHmj73QUVFJ1G8sC6GayjJKIIbt+cgFVYkXVcGpQke9NsvLz/yLUnTya8xHzio1BQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lgOB1tMmxDt7Vh6zexkxbNfm8YqJy0OQRgjBYN7c08Q=; b=NbMP64Cv8Vr+yP7bEnalSvEg7qUmYjxr1MyJWuglTweaX4iYE6aKwpdIPGJGHLs7eXwJT3ooAczscFE6/NVMqKJ464C9/nXFylXSqpmLzKHSg7wahvRIg3/yfMeqH/AbFiaK4EWmf7YG8FhlzzbWKZ3C0KQ2iNEYZJIBffjvYbc= Received: from BN8PR12CA0006.namprd12.prod.outlook.com (2603:10b6:408:60::19) by DM5PR12MB1129.namprd12.prod.outlook.com (2603:10b6:3:7a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Wed, 29 Jan 2020 22:51:15 +0000 Received: from BL2NAM02FT006.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e46::201) by BN8PR12CA0006.outlook.office365.com (2603:10b6:408:60::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20 via Frontend Transport; Wed, 29 Jan 2020 22:51:15 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT006.mail.protection.outlook.com (10.152.76.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.25 via Frontend Transport; Wed, 29 Jan 2020 22:51:15 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 00TMpDf6011608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 29 Jan 2020 17:51:14 -0500 To: rum@ietf.org References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Wed, 29 Jan 2020 17:51:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158033443345.2803.14350232562292068648@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(136003)(376002)(189003)(199004)(31696002)(7596002)(70206006)(70586007)(5660300002)(26005)(786003)(316002)(75432002)(36906005)(2906002)(86362001)(6916009)(53546011)(336012)(956004)(2616005)(966005)(26826003)(356004)(8676002)(66574012)(246002)(478600001)(186003)(31686004)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1129; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2dc8e145-67df-4712-68b9-08d7a50dbedf X-MS-TrafficTypeDiagnostic: DM5PR12MB1129: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02973C87BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ulALxKNjJkwP4OJvbB9byYi3BWJUbvdgX+6ZdHAI6Q16ct5QIPqJXjdJUFqyruTkCHaPn4chbk+j66+KjdyhUQzzpcEqvIWQxGJ7LYLHMYCqhvJJYVArx/vGDPo8NSU3DyJDqDIk2FEzlGLCDob4jVQSyCwKj3MnAP3MxdMormrzAUgVJxhvgN9VkOWyqQdpBbZeejp4Bw7z0GuJ+LPlpCmBfJ9njxVIYenpHBpTCSwmVNoj1q2ioqV9gAdRqULkjhDBgIRHYfXDhU2iAze6OoI45IKLChddyQ3KESuoYoy6ev3LP5TvBDpSsFyEjjiBuRkR5Ne4G+WcELbKAvcGUYoeDr8M1iArgNifRVpsFAbuLMYj6L1R+PWAFyYZLvuHBVfxfkAzOR0MZbLfJ+TY3zvMq37jFDukFUiz/TtrTfVOs4E+97S9olOPpzt8TECkRY6D9lsffJcfPSY0JKCufZy0zpsO43dAH3w0SR2eMDVJbJfKDbbmPjcQMD3sojPQyZR/7MH6u3M26S7GqhHw+g== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2020 22:51:15.1104 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2dc8e145-67df-4712-68b9-08d7a50dbedf X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1129 Archived-At: Subject: Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 22:51:20 -0000 Brian, Thanks for the update. I think I will have a number of questions once have more time for study, but I have one right off: Section 9 says that there is one file for device configuration. That won't make it practical for a single RUE to support a user with accounts with multiple providers. Rather, to be workable it will be necessary for there to be a configuration file for each provider that the user of the RUE uses. The exact mechanism for setting that up needs to be worked out. Perhaps it would be sufficient for there to be another entry, for each provider, in the provider list file that is used by the RUE to retrieve the configuration for that provider. Thanks, Paul On 1/29/20 4:47 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Relay User Machine WG of the IETF. > > Title : Interoperability Profile for Relay User Equipment > Author : Brian Rosen > Filename : draft-ietf-rum-rue-02.txt > Pages : 28 > Date : 2020-01-29 > > Abstract: > Video Relay Service (VRS) is a term used to describe a method by > which a hearing persons can communicate with deaf/Hard of Hearing > user using an interpreter ("Communications Assistant") connected via > a videophone to the deaf/HoH user and an audio telephone call to the > hearing user. The CA interprets using sign language on the > videophone link and voice on the telephone link. Often the > interpreters may be supplied by a company or agency termed a > "provider" in this document. The provider also provides a video > service that allows users to connect video devices to their service, > and subsequently to CAs and other dead/HoH users. It is desirable > that the videophones used by the deaf/HoH/H-I user conform to a > standard so that any device may be used with any provider and that > video calls direct between deaf/HoH users work. This document > describes the interface between a videophone and a provider. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rum-rue-02 > https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-02 > > > 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 Jan 29 15:04:26 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D616E12004C for ; Wed, 29 Jan 2020 15:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 oX6RV5KA9Hii for ; Wed, 29 Jan 2020 15:04:21 -0800 (PST) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 52A3E120047 for ; Wed, 29 Jan 2020 15:04:21 -0800 (PST) Received: by mail-yw1-xc2a.google.com with SMTP id h126so893057ywc.6 for ; Wed, 29 Jan 2020 15:04:21 -0800 (PST) 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=LessnoYMQnLkQ1ON+D/jn8LUI4wPwEyiLNh/wstQ5FA=; b=p5VUKnYfuoKlggeaQM5mRyXPnAWkQfQBx7yynBtzIBe0a7171eHoDs9EjXDy3afFtg MOIz/555YwM6Td5j+1DZT7UC0dRuWjOENM00z2bF8uZIBH5QsY2IcElW4jZa2nIAMVJS P2Y/DbnJUE+YlBYUIbIeZ9Ftr3+b3zXnSw+ErzTNH1KLAQw41x78dQDbTcq3NYE0rky/ dEatNJQbjugy+aJzQ/eKyoRT7rbAdX5Gqhj3Z5HnFmDAs78LcIdAOXYIa79zuVoaH1gS DBIOCGlUxBODRW96bqYVJXZXW5Ql7s46uxZduTKSVKxjoPfLf5uz1PdfhuG/+ZllSakz E6DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LessnoYMQnLkQ1ON+D/jn8LUI4wPwEyiLNh/wstQ5FA=; b=T7RoqE4uivLjU756Rr6waMGOsVfxV+XpZu3hpUdEOzjC5j/mps9hYNG8QKknHwY8DJ +MMJtd+nE8QLNWjlr3/RQIhDvGdjyAxZfOrT1Ql2+hFSuqk8i06Tbdj2vZaxjB26vJmg wW9pF1It36MOvFiBKmyVC5ulr+f2+WDiftkeoFUnLGhdne2aKhiQ4OXHQfKzDTA+GMxj TvqCHWlg0QX0IIvABQQvG/GN9YEBOfqZRR8zKnghHcfmAIE69HDlxLc/Oxkb3gn3Cnq3 Uue3yBHmQ72UN26VQqjQ1GG+1lZOE1EAos7tQYSns2Ab44TIhrbcvmQv/F7ma6/6WPVw L0qA== X-Gm-Message-State: APjAAAWLsz9Fk3cYtJJsJ6mlDDuJfJ96GM/1Y9jNSgLlsRP4JCmtwDBP WxkzA+BgDv2GnZWdJ97acezSlg== X-Google-Smtp-Source: APXvYqz+GT+18hRnEEk774hAO0JMnrTAqFIjFd9tIcQ6zOWbncXrnCkgf0TFdT2aELt1ZZBKowoctg== X-Received: by 2002:a25:cf0b:: with SMTP id f11mr1609142ybg.469.1580339060335; Wed, 29 Jan 2020 15:04:20 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id o205sm1617265ywb.58.2020.01.29.15.04.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jan 2020 15:04:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: Date: Wed, 29 Jan 2020 18:04:18 -0500 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 23:04:24 -0000 The configuration file mechanism needs work. The current mechanism supports multiple providers in that it allows = multiple username/passwords. That=E2=80=99s probably insufficient. For example, each provider may = have their own TURN server. Probably, we want to allow any of the = parameters to be either in the =E2=80=9Ctop level=E2=80=9D part of the = object, in which case they apply globally, or in a per-provider part of = the object in which case it only applies to that provider. There is also the issue of cleartext passwords. I was thinking about that, but didn=E2=80=99t really work out a = solution. What I=E2=80=99m thinking about is that maybe there is a = single username/password that unlocks the file, and in the file are = per-provider records. The device itself manages the encrypt and decrypt = of the file. I wondered if we could use .well-known, plus that username, to find the = file at the default provider=E2=80=99s website, as listed in the = provider file, but the user may have more than one TN at more than one = default provider, so I got back to a pre-provisioned URI. This update does address all the issues I knew about. I got a private email that told me the example config file didn=E2=80=99t = lint, and I found two errors that I=E2=80=99ll get into the next = revision. Since we=E2=80=99re likely to change that part of the = document anyway, that=E2=80=99s no big deal. Someone also asked about why we specified STUN/TURN in the config, but = didn=E2=80=99t mention it anywhere else. It gets into the requirements = via the WebRTC transport spec, which requires ICE, which requires = STUN/TURN. So technically, it=E2=80=99s okay, but do we want to point = that out? Brian > On Jan 29, 2020, at 5:51 PM, Paul Kyzivat = wrote: >=20 > Brian, >=20 > Thanks for the update. I think I will have a number of questions once = have more time for study, but I have one right off: >=20 > Section 9 says that there is one file for device configuration. That = won't make it practical for a single RUE to support a user with accounts = with multiple providers. Rather, to be workable it will be necessary for = there to be a configuration file for each provider that the user of the = RUE uses. >=20 > The exact mechanism for setting that up needs to be worked out. = Perhaps it would be sufficient for there to be another entry, for each = provider, in the provider list file that is used by the RUE to retrieve = the configuration for that provider. >=20 > Thanks, > Paul >=20 > On 1/29/20 4:47 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Relay User Machine WG of the IETF. >> Title : Interoperability Profile for Relay User = Equipment >> Author : Brian Rosen >> Filename : draft-ietf-rum-rue-02.txt >> Pages : 28 >> Date : 2020-01-29 >> Abstract: >> Video Relay Service (VRS) is a term used to describe a method by >> which a hearing persons can communicate with deaf/Hard of Hearing >> user using an interpreter ("Communications Assistant") connected = via >> a videophone to the deaf/HoH user and an audio telephone call to = the >> hearing user. The CA interprets using sign language on the >> videophone link and voice on the telephone link. Often the >> interpreters may be supplied by a company or agency termed a >> "provider" in this document. The provider also provides a video >> service that allows users to connect video devices to their = service, >> and subsequently to CAs and other dead/HoH users. It is desirable >> that the videophones used by the deaf/HoH/H-I user conform to a >> standard so that any device may be used with any provider and that >> video calls direct between deaf/HoH users work. This document >> describes the interface between a videophone and a provider. >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-rum-rue-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-02 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-02 >> 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/ >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Jan 29 19:03:12 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5207F12006E for ; Wed, 29 Jan 2020 19:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 4_SISkOUkNPG for ; Wed, 29 Jan 2020 19:03:08 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750080.outbound.protection.outlook.com [40.107.75.80]) (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 2945C12006D for ; Wed, 29 Jan 2020 19:03:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WBkv+9a030HAt+YJXRePXaSQAVTKlR+PuBXDFp1UGRYrAjug00kkSKC1HcBLeYs6WcaHLsv+hTgR1a6zbu++2BTyu0TQPjwIzUrvI9i4ofv0uG5uWjft5sNd/O7vr704F4E6YTl5BRVQI9YSzJceudSc4a3eTund0AUProSaMWUCsLheHwAuk+bMauFM1wD1wdwhrdTGYx4uqTbM66hYjECq4dG29aL+sKFY8EUr/ou/EhzhteOJiYrAH9KbwYaeXekHsN6C3r96qoxuRSSvxutp7rWzJrNfNBoy6738rocs3gSmfa6S429ImzoeQLYIwVqJuiFLoWJTKuznBF+Z9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9wjWauOgTy28Xzbedcbny1MnL+qXJq/bEOBE5Rmxryo=; b=XB8mo0UCPGcDoIg8qeCDAeKITSNmjqw4S83zDA+42MuF0PPO9YW5B/AhCp2Uzg/B3CGQVr3pWKqGBP8KqfB5eIzzBp5S+5XOOuAa9lAOsIxxEDf5FPcoseWrkMYG9REJ0lrbDe/EOYT25rQEaen10Sj7AoMPVzfceDZ7ZDusMHx5EzYFLn2zijUNtfU7XZf61H/jb/PgsP9ttBHngzDpqJ7OdSI4fls1uNbOL4RzsLdH1OqH9OdrbKNRFiRIeeURTCQrLYiXxTRfyd/3sZNmWa1qKTJFi+TGJ6CYtfipRFW5tEtHKubzEcw+dSP3GHdK3rEMEfXskhR2oEMGZlyBKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9wjWauOgTy28Xzbedcbny1MnL+qXJq/bEOBE5Rmxryo=; b=QmXZVhGrr5Nwe32aWALax6hUSqP6FY/FdQsVKsSfIAWEZdHOIvAJO1SFAJ3qA+IJbcx5b5LRVY2bnsrq78dSK81PgfqCXfq9+VpUHtXm35KHSTGCV81oX70AZa60z7x0hmIOYT8l/li6dSn1RylpjOOUuTDGF04nRC4bJ0Vymco= Received: from MN2PR12CA0024.namprd12.prod.outlook.com (2603:10b6:208:a8::37) by DM5PR12MB1706.namprd12.prod.outlook.com (2603:10b6:3:10f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Thu, 30 Jan 2020 03:03:05 +0000 Received: from CY1NAM02FT028.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::202) by MN2PR12CA0024.outlook.office365.com (2603:10b6:208:a8::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22 via Frontend Transport; Thu, 30 Jan 2020 03:03:05 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT028.mail.protection.outlook.com (10.152.75.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.25 via Frontend Transport; Thu, 30 Jan 2020 03:03:04 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 00U332QI026714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jan 2020 22:03:02 -0500 To: Brian Rosen Cc: rum@ietf.org References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Wed, 29 Jan 2020 22:03:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39860400002)(136003)(199004)(189003)(246002)(31686004)(786003)(356004)(53546011)(478600001)(316002)(6916009)(70586007)(26005)(75432002)(86362001)(70206006)(8936002)(66574012)(36906005)(4326008)(186003)(5660300002)(31696002)(966005)(336012)(8676002)(2906002)(26826003)(7596002)(956004)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1706; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f462773-949f-49d2-913b-08d7a530ecdc X-MS-TrafficTypeDiagnostic: DM5PR12MB1706: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02981BE340 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0BITS3iMILrDPxBxgX7xBlZ2p+M+tfmmJoBLQLTZIeR9j9KLmNZn6raGSYVu3IjF5r/pxbBpfSMp4bH+fTmTImnU8zHNLtlfsM1ZhFHKYAaf4Onb/4PBpLedrZy+ihlsy4p1ir4PR7+VLHn0x6x1nEU/xLKycx93fhgdZAr/UlDLVpLoGbG1q7lvexprFp21BdhURiX+OBpYiRDcmvfuA0ufpF0gm3KWZUBbwMyTIPJhd1UjfBDgcROZn7EKuoGfyBDLxZAVfiXGDRhY4fMqaMuXYX5eBRyKIEeVx0NJUZDRV/CwioRcL84qNUyEN/lKJIr4RDwhtauzPl60an2jtFHbwUJzKKJiaOXtzuH4HGqhxApmUNCT17SVwTVXZ0jIYApq+jqgaRaAY5SwnbYGrcLw7xV3JjdDHafdbadDKPmCZIK65JLjDC1gepuVEKvhM8bl4CMzTKi2OJEUBXPPvX1HgCYfl+G9s2sTsEzIUNlBWTAB/Jokn2dLTJrVttgWgnaHg9VcrF5u96ueHOx8QQ== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2020 03:03:04.4313 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5f462773-949f-49d2-913b-08d7a530ecdc X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1706 Archived-At: Subject: Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 03:03:11 -0000 On 1/29/20 6:04 PM, Brian Rosen wrote: > The configuration file mechanism needs work. > The current mechanism supports multiple providers in that it allows multiple username/passwords. > That’s probably insufficient. For example, each provider may have their own TURN server. Probably, we want to allow any of the parameters to be either in the “top level” part of the object, in which case they apply globally, or in a per-provider part of the object in which case it only applies to that provider. IMO that isn't good enough. It just isn't workable for a single config file to contain one RUE's config information for multiple providers. Where would it live, and who would manage it? Each provider needs to be able to manage its own config data. Perhaps there should be *some* config data that is per-RUE rather than per-provider account, and is managed by the end user rather than the providers. For instance, the user might want to make his own choice of where to sync his address book instead of or in addition to a provider-managed server. But I think that could be a local config issue between the RUE and the user. Thanks, Paul > There is also the issue of cleartext passwords. > > I was thinking about that, but didn’t really work out a solution. What I’m thinking about is that maybe there is a single username/password that unlocks the file, and in the file are per-provider records. The device itself manages the encrypt and decrypt of the file. > > I wondered if we could use .well-known, plus that username, to find the file at the default provider’s website, as listed in the provider file, but the user may have more than one TN at more than one default provider, so I got back to a pre-provisioned URI. > > This update does address all the issues I knew about. > > I got a private email that told me the example config file didn’t lint, and I found two errors that I’ll get into the next revision. Since we’re likely to change that part of the document anyway, that’s no big deal. > > Someone also asked about why we specified STUN/TURN in the config, but didn’t mention it anywhere else. It gets into the requirements via the WebRTC transport spec, which requires ICE, which requires STUN/TURN. So technically, it’s okay, but do we want to point that out? > > Brian > > >> On Jan 29, 2020, at 5:51 PM, Paul Kyzivat wrote: >> >> Brian, >> >> Thanks for the update. I think I will have a number of questions once have more time for study, but I have one right off: >> >> Section 9 says that there is one file for device configuration. That won't make it practical for a single RUE to support a user with accounts with multiple providers. Rather, to be workable it will be necessary for there to be a configuration file for each provider that the user of the RUE uses. >> >> The exact mechanism for setting that up needs to be worked out. Perhaps it would be sufficient for there to be another entry, for each provider, in the provider list file that is used by the RUE to retrieve the configuration for that provider. >> >> Thanks, >> Paul >> >> On 1/29/20 4:47 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Relay User Machine WG of the IETF. >>> Title : Interoperability Profile for Relay User Equipment >>> Author : Brian Rosen >>> Filename : draft-ietf-rum-rue-02.txt >>> Pages : 28 >>> Date : 2020-01-29 >>> Abstract: >>> Video Relay Service (VRS) is a term used to describe a method by >>> which a hearing persons can communicate with deaf/Hard of Hearing >>> user using an interpreter ("Communications Assistant") connected via >>> a videophone to the deaf/HoH user and an audio telephone call to the >>> hearing user. The CA interprets using sign language on the >>> videophone link and voice on the telephone link. Often the >>> interpreters may be supplied by a company or agency termed a >>> "provider" in this document. The provider also provides a video >>> service that allows users to connect video devices to their service, >>> and subsequently to CAs and other dead/HoH users. It is desirable >>> that the videophones used by the deaf/HoH/H-I user conform to a >>> standard so that any device may be used with any provider and that >>> video calls direct between deaf/HoH users work. This document >>> describes the interface between a videophone and a provider. >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-rum-rue-02 >>> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-02 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-02 >>> 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/ >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > From nobody Thu Jan 30 10:00:31 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15CD1208BB for ; Thu, 30 Jan 2020 10:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 WDlAvEmUI69e for ; Thu, 30 Jan 2020 10:00:25 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2089.outbound.protection.outlook.com [40.107.237.89]) (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 18CB9120816 for ; Thu, 30 Jan 2020 10:00:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dh0K/UCjSu1bRgOpuJUIxEiMLdxax2tTA50P0VcpWbyyraUTMyFDLdlC/m4w2hmTBsa6GSmg5wrWg1JbHdlUchnqO5NGKVAI8DHBdCywjZFeZQCphMY6X1nxuV+nVR8pgt5pZ1yv4rgxQK9IF1FinR5rhFeFq4TtcH2qVwUymdEeIx3LD0ODxdp2sBZE2mXzPhfpBVqvjHaGdk+DPaqF46FZK19pZAJav8cR2CBUIjg6b2Na3Orb6RNnPXfhJPLZWQys+mXu2FPKIPJWrVhLIuXTd5gX1Fv+ebK6vxt9PD5Kk2mowfaSO7y94hAfrkxwxUFAVjFDIr5Eo4TPPTIoUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3QUU5WVwZm3SCpB8fneUAEvcjg4IwhW72JhZfIivPnA=; b=Bd1g0NXDONFJZDtFBcGENpug5A/E9wi//lkmcjLrnwifrzCw+Qk63iurtVrBLxezLiNDK4hhX2rIBhOUnoQ6LN11rpzct/QAWbuBKmi4Cz8uXw4eahkjzLk0N7S720jnjkODVseFXAheB9OxEfT9sX639ZKZRqnt43bt3eWFeeNbF/1A4Yv+jV7AfGZKPpug5AaiSdiZBD2Cqg0AZ6OaXI8GnPgkzXpg3koW9S7n+fJDt0AJw3ixbLEZ4g89SZhLq7DuUOQPzOK5ltRNxIWJKAlQRnKzqt5aD88w/2Ml0Rea2KRBseDibUVS9ccAmOYViuxdyvCJaPEnCPQUfO+G9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3QUU5WVwZm3SCpB8fneUAEvcjg4IwhW72JhZfIivPnA=; b=dC1uF/eBAoEfpiO4EzNBJeDQUWnoBvydzdALuTZaPQuoHWQQrpqFT8E9ScmwQlTC7p4p8hJVOejLLAZJlw1emhid0cuHxEj5p/PCx+3eOvdvnV7hoO2ksHp01V/vIKYj4+Xg8qS2XSrxDYKQ4SptAkScU2EwSb7Niihp91y2jCc= Received: from DM3PR12CA0076.namprd12.prod.outlook.com (2603:10b6:0:57::20) by DM5PR12MB2358.namprd12.prod.outlook.com (2603:10b6:4:b3::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Thu, 30 Jan 2020 18:00:22 +0000 Received: from SN1NAM02FT027.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::200) by DM3PR12CA0076.outlook.office365.com (2603:10b6:0:57::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22 via Frontend Transport; Thu, 30 Jan 2020 18:00:22 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT027.mail.protection.outlook.com (10.152.72.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.25 via Frontend Transport; Thu, 30 Jan 2020 18:00:21 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 00UI0J1G014046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 30 Jan 2020 13:00:20 -0500 To: rum@ietf.org References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Thu, 30 Jan 2020 13:00:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158033443345.2803.14350232562292068648@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(199004)(189003)(336012)(316002)(186003)(786003)(2906002)(7596002)(36906005)(75432002)(478600001)(26826003)(246002)(31696002)(6916009)(5660300002)(86362001)(2616005)(956004)(70206006)(8936002)(8676002)(31686004)(26005)(70586007)(356004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB2358; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 20125c05-4347-4b54-39c3-08d7a5ae4677 X-MS-TrafficTypeDiagnostic: DM5PR12MB2358: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02981BE340 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: RfzLIHqEnkUOFTf9hObk24eGn4RHRcjgWDnciTiqtLebvr1DdVgXCRBdn88lC6rLUQMXJ1SZxF+qM4uDu+zIeo47tsqnZecx2Pw8kevQKQfsaYEHyxYV4e2bsxTh1kO2UFUrqbhlZu6rYWMRPL9i3U1M4QnyDJ9pSx8p48Y8EC84HypiLWg9ncsiEw4sjFx1VXLP1uM28+r7ABf6YndsK1r9pvGo5Lxru3PF8sACiUfoJBK14T7BQIU3iK/JiINaHsaNdmKz1E/oxTo6h4PqsMFVxBs6TlXOFrjWNBzlzwnNlZW69TXqcXaSoYLe3R9JT70BSJfLuOA9doGn9HhgBL3ZUX/mzVbN6t3bJCAEjBDHA2q8kIXb8KYg5fz1pDOuOpR1gCSh6NOTQVAOLOBqRhURyOMmeIknK03XoG6jQjbApzLSLGSGwLvyW2GGccI9 X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2020 18:00:21.9904 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 20125c05-4347-4b54-39c3-08d7a5ae4677 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB2358 Archived-At: Subject: Re: [Rum] draft-ietf-rum-rue-02.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 18:00:30 -0000 Here are some further comments on -02: This update has largely expunged separate specifications for the RUE and the provider server the RUE connects to in favor of talking about the RUE Interface that both are required to implement. In some cases that makes sense because the requirements are the same on both sides. In other cases it seems to dodge the issue that the two sides have different roles and responsibilities. For instance: RFC5626 (outbound), RFC6665 (events), RFC6442 (geoloc). Section 5.2.1 now says: The all outbound calls MUST be routed through an outbound proxy if configured. (It previously specified the RUE.) IIUC this really does only apply to the RUE. AFAIK we don't specify any configuration for the provider, and presumably providers can do whatever they want that works. (Also, the language is a bit messed up.) Section 5.2.3 says: To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK accepting a call by a RUE, identifies the owner by sending a Call-Info header with a purpose parameter of "rue-owner". This new purpose parameter needs to be registered with IANA. It currently isn't mentioned in section 11. Section 5.2.5 says: The implementations comply with [RFC6881] for handling of emergency calls. This is not a normative statement. AFAICT there is no normative requirement to support this. And this is another asymmetric case. (IIUC the provider need not include GeoLoc in outbound calls to the RUE.) This section also uses "client" and "server" to refer to the RUE and Provider sides of a RUE Interface. This differs from using "client" to refer to UAC and "server" for UAS. Section 5.5 and elsewhere use the following construction: Implementations MUST conform to ... with the understanding that ... That language seems a bit vague to me. Is this relaxing any normative statements in the reference, or simply stating that only a subset of the standard will be used in practice? I'd like to see this tightened up normatively. Section 6.3: I think this is saying that RUEs MUST support VP8 unless they can't, while providers MUST *support* VP8 but need not use it in every call, such as when connecting to another endpoint that doesn't. I get the spirit, but it fails to make clear when an implementation is non-conforming. For instance, is it acceptable for a provider's interpreters to use non-RUE devices that don't support VP8? Is it acceptable for the provider video-mail server to not support VP8? Section 8: IIUC this means that the provider may or may not include a "mwi" entry in the configuration, but if it is configured that both sides are required to support it as specified. Section 9.1: This makes it optional for a RUE to make the choice of provider available to the user. Is that what we want? Section 9.3: These schemas use the [JCR] notation. This dates back to the early versions of this document several years ago. At the time there was single accepted schema notation for JSON. JCR was under development at the time. I haven't kept up with what has been happening with JSON schemas. I just looked and it appears that draft-newton-json-content-rules-09 is the latest version of JCR. I don't know if that means it was abandoned in favor of something else. We need to investigate this. Thanks, Paul