From nobody Wed Jun 9 10:00:50 2021 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 13CC13A1EAF; Wed, 9 Jun 2021 10:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: pkyzivat@alum.mit.edu, rum-chairs@ietf.org, rum@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162325804857.9820.1485439932676939951@ietfa.amsl.com> Date: Wed, 09 Jun 2021 10:00:49 -0700 Archived-At: Subject: [Rum] rum - New Meeting Session Request for IETF 111 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, 09 Jun 2021 17:00:49 -0000 A new meeting session request has just been submitted by Paul Kyzivat, a Chair of the rum working group. --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Paul Kyzivat Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch sipcore ecrit mmusic Technology Overlap: quic People who must be present: Murray Kucherawy Brian Rosen Paul Kyzivat Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 14 14:39:04 2021 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 AEDC63A0E08; Mon, 14 Jun 2021 14:39:00 -0700 (PDT) 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: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rum@ietf.org Message-ID: <162370674060.2403.4113687365962969096@ietfa.amsl.com> Date: Mon, 14 Jun 2021 14:39:00 -0700 Archived-At: Subject: [Rum] I-D Action: draft-ietf-rum-rue-05.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: Mon, 14 Jun 2021 21:39:01 -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-05.txt Pages : 33 Date : 2021-06-14 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 deaf/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 is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-rum-rue-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 14 14:41:18 2021 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 BAD323A0E11 for ; Mon, 14 Jun 2021 14:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 CDqKiSTYH5kM for ; Mon, 14 Jun 2021 14:41:10 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 7B0B73A0E0D for ; Mon, 14 Jun 2021 14:41:10 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q7so41258302iob.4 for ; Mon, 14 Jun 2021 14:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=BjYyQgYMAO59uonmq4QGAQA6UG+yrK4dz7XVoxGvtDE=; b=QsTsbaRbSKWHJwDqNWYMPgQNE6gitebbiRfNZ7yqLuFVd8pcrERjXHrdv82SSmnhds lT0Z0LRf4dCOvslAHPfKDYQZ7aBkKTYDUsQAaM0777D+jByIOW/6xg9tdvHYkXqBqGRA iJxuzjySmrycGQTDIfbbsFWNLl3iM0ZneXeG8d/9UuMnn2d1+jLNqSAUHS8drTjbN03P PMI5B/CbkMmLMwCZT7/6KxnFsh12KUcGCwbnVTaNx8GMsMjPemjYoMNPTxBOy6WNKepR vKRvZlwY8ztFz12tvAPrrnSOwsRpDsPa31Vc/90D7GmrqGC+T2lAx5qPcKF4nRhofJSy KSnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=BjYyQgYMAO59uonmq4QGAQA6UG+yrK4dz7XVoxGvtDE=; b=pJ+hw2wA/i5Dj2Kwe8zzF7ZbxUXYd+vaM2xLSyBqbSESJ/EAT3jdsw4x9PhLiag/v7 a5rOm2wlQb/NhwZH2H8j0BmrcpMhlxhhvtwn+N0WwxifYcwwyaQFCNO+8HF67clz9jEs XWyntclkfFudZPGYdzzQHU/w2VjfJGBEXQ51ZToPe//B9s0Nr7+EDaFV/thGOtvCQpyW Iomcak85f81vmQoM0UwlNrPmc1iyDUGNHUZ5LMm9xC7yet1Yq/XC6J9REN3HYSNXio2e zFHRBwZibRMIejs18j8rA/GlQy/6bTzl9XUj6rpiwlGzAqWlrpnUCTohFv3VnbN45wdR ipJg== X-Gm-Message-State: AOAM531Phg0n3cx7LWKst7Ug00AGZlqLEpIKIhQC1lRJ9j4kzFt1lgfe LoR/zpHzHBFFsCfahSGgRzHybMdvm48VZ9UEqII= X-Google-Smtp-Source: ABdhPJwcIpV7i+01iyDmEkSIrRglzDpWWW4yxg5TNlUaSQgrFZWAPWRFuwJaz3L9/AuU5JZpXpcc3w== X-Received: by 2002:a6b:f81a:: with SMTP id o26mr7785627ioh.56.1623706869294; Mon, 14 Jun 2021 14:41:09 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id p10sm8540988ile.35.2021.06.14.14.41.08 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Jun 2021 14:41:08 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_CF8DC0BC-A317-4C38-8460-F90BBCE0CB38" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: Date: Mon, 14 Jun 2021 17:41:07 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Rum] New Version has some changes requested, and not others 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: Mon, 14 Jun 2021 21:41:17 -0000 --Apple-Mail=_CF8DC0BC-A317-4C38-8460-F90BBCE0CB38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The latest (-05) version=C2=A0 = of rum-rue has a = number of changes requested by commenters including: I changed the digest requirement to require RFC8760 and mandate at least = SHA-512 support. There isn=E2=80=99t any good reason I can think of to = make the mandatory algorithm specified in the configuration. Once you = implement SHA-anything with any current library, you get SHA-256 and = SHA-512. Support doesn=E2=80=99t require a change in password, but it = does require an operation to recalculate the digest. I think that=E2=80=99= s reasonable, and it=E2=80=99s easy to support backwards compatibility = in the server side with both MD5 and SHA-512 with one password and two = digests. The text does specify that the username/password for REGISTER = must be different from other uses like websites and support services. Added password in the configuration. It=E2=80=99s optional. If it=E2=80=99= s returned, the device retains it, and uses it for SIP/STUN/TURN for = subsequent invocations. If it=E2=80=99s never returned, then the = credentials for the configuration interface are used for SIP/STUN/TURN. I added an instance identifier to the configuration data query to = support emergency call location. I noticed I hadn=E2=80=99t defined the = API Key parameter in the OpenAPI yaml, so I added both parameters in = this version. Support for SIP PUSH (RFC8599) is required if the RUE/Provider supports = mobile devices/clients I did not make several requested changes. It will be a chair call, = assisted by Area Directors, to determine if rough consensus exists to = make this changes, and if there is, then I will do them. As editor, I = am obligated to make the document conform to rough consensus as = determined by chairs, and I will do so to the best of my ability. I left IPv6 required. We basically don=E2=80=99t do IPv4 work anymore. = It would be tough for a new document like this to get through the IETF = with only V4. Both ends are mandated to support V6. I did add text = using my interpretation of the SIPconnect no-dual-stack-required text. = It says you can have more than one server specified in the SRV record, = where each server has an A or AAAA record, but not both. You can, of = course, support dual stack if you want to. I left the contact sync as is for now. Let=E2=80=99s see what rough = consensus is. I could change from jCard to xCard but that really does = seem backwards for a new spec. I have reason to believe there would not = be a problem with the US FCC over using jCard. YMMV. Again, I will go = with rough consensus on that. Having done conversions from one to the = other, I know it=E2=80=99s easy. It=E2=80=99s just syntax, not = semantics. I don=E2=80=99t feel all that strongly about dropping VP8 video codec = support, but I=E2=80=99m reluctant to lose WebRTC compatibility. I feel = much more strongly about retaining support for OPUS. Again, I will go = with whatever consensus we have. We deliberately put support for = compatibility with WebRTC in the charter. A gateway to SIP would be = required to use it. What we have in our spec is mostly the media stuff, = not the signaling. I feel strongly that MWI support is required as there are no other = standards for this functionality and proprietary-only seems wrong to me. = Again, we=E2=80=99ll have to determine consensus. There was other list = traffic in support of MWI. =20 Brian --Apple-Mail=_CF8DC0BC-A317-4C38-8460-F90BBCE0CB38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The= latest (-05) version of rum-rue has a number of changes = requested by commenters including:
  • I changed the digest requirement to require RFC8760 and = mandate at least SHA-512 support.  There isn=E2=80=99t any good = reason I can think of to make the mandatory algorithm specified in the = configuration.  Once you implement SHA-anything with any current = library, you get SHA-256 and SHA-512.  Support doesn=E2=80=99t = require a change in password, but it does require an operation to = recalculate the digest.  I think that=E2=80=99s reasonable, and = it=E2=80=99s easy to support backwards compatibility in the server side = with both MD5 and SHA-512 with one password and two digests.  The = text does specify that the username/password for REGISTER must be = different from other uses like websites and support services.
  • Added password in the configuration.  It=E2=80=99s = optional.  If it=E2=80=99s returned, the device retains it, and = uses it for SIP/STUN/TURN for subsequent invocations.  If it=E2=80=99= s never returned, then the credentials for the configuration interface = are used for SIP/STUN/TURN.
  • I added an instance = identifier to the configuration data query to support emergency call = location.  I noticed I hadn=E2=80=99t defined the API Key parameter = in the OpenAPI yaml, so I added both parameters in this = version.
  • Support for SIP PUSH (RFC8599) is = required if the RUE/Provider supports mobile = devices/clients


I did not make several = requested changes.  It will be a chair call, assisted by Area = Directors, to determine if rough consensus exists to make this changes, = and if there is, then I will do them.  As editor, I am obligated to = make the document conform to rough consensus as determined by chairs, = and I will do so to the best of my ability.
  • I left IPv6 required.  We basically = don=E2=80=99t do IPv4 work anymore.  It would be tough for a new = document like this to get through the IETF with only V4.  Both ends = are mandated to support V6.  I did add text using my interpretation = of the SIPconnect no-dual-stack-required text.  It says you can = have more than one server specified in the SRV record, where each server = has an A or AAAA record, but not both.  You can, of course, support = dual stack if you want to.
  • I left the contact sync as = is for now.  Let=E2=80=99s see what rough consensus is.  I = could change from jCard to xCard but that really does seem backwards for = a new spec.  I have reason to believe there would not be a problem = with the US FCC over using jCard.  YMMV.  Again, I will go = with rough consensus on that.  Having done conversions from one to = the other, I know it=E2=80=99s easy.  It=E2=80=99s just syntax, not = semantics.
  • I don=E2=80=99t feel all that strongly = about dropping VP8 video codec support, but I=E2=80=99m reluctant to = lose WebRTC compatibility.  I feel much more strongly about = retaining support for OPUS.  Again, I will go with whatever = consensus we have.  We deliberately put support for compatibility = with WebRTC in the charter.  A gateway to SIP would be required to = use it.  What we have in our spec is mostly the media stuff, not = the signaling.
  • I feel strongly that MWI support is = required as there are no other standards for this functionality and = proprietary-only seems wrong to me.  Again, we=E2=80=99ll have to = determine consensus.  There was other list traffic in support of = MWI.  
Brian





= --Apple-Mail=_CF8DC0BC-A317-4C38-8460-F90BBCE0CB38-- From nobody Thu Jun 17 08:09:54 2021 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 700AE3A23A1 for ; Thu, 17 Jun 2021 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 BqUDziHBE_Rs for ; Thu, 17 Jun 2021 08:09:47 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2059.outbound.protection.outlook.com [40.107.223.59]) (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 C8F113A23AB for ; Thu, 17 Jun 2021 08:09:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hKWfRSbc23WeZw9ZNrdT6lr4QdQWoNkSClDinwMolboVsD2tBG5PVvs8xIBAn4VSImfXsY4dWXKmX6KHeYhzaTJytM1cspKS2r7OaYNE5G/Bq7GF+2vO3PpitBsriHBL5hNYJfm7XzZrAMBGmll134jaJYMwAmSb++zYJCV+tklOaCWYw+WA5+eTSslTKICMaNMFTSDY8CP9Kc9WYn0zwjtxISCjJ4/mv0kvVKJE1zWBLx3AxB3YZdb+WudhEdl5VqRXCJbwscemlBarmBSL6bJ/TTLHv/xob99jRLQIAUfkpKGL3FMiLSjSxYwtwmG5vBsWxDkoXBgglEVUEJwoQw== 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=s6FBrNFuJlgAy4L4Qo5Gvtk9ztVkxRJ47f6diE/NUH0=; b=iU0TdjzTw6Q0oNDCRUJtywHv9iOFfrkKuJ1s5JDgRI+whsIktbyNcRTdOC/SqhX5w/a57B7cgkf1H7WDCaLUZGUD8OycftEa9xpZIvnQnGESHBESGwHyVxEDRLPr2FRYk5mJooBY9lsIbqDiDarfaoQe1fXOjb+BINQS6K2UcmeUlnsGxAF9/yVoiIdI3fUpO+FRged83ec+lxiWcgB4oNQEsOjY6aUyxdzuLFIM0zhOMHKHe6B7XIuArpdwxd8fLZsbH+9FXW+CCyf5cePyu7+zfJveBz2M45SEwj12AooaNdwBjwobx+YyJ2z6tJHlRrHEJ0BkoDWAkdbAkD7y6Q== 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=s6FBrNFuJlgAy4L4Qo5Gvtk9ztVkxRJ47f6diE/NUH0=; b=WspPpAfnLhsnv9z27Yg0C94eZciWeOYWfENuYMw1SikZYkF1XetzOz7RPOC4CIQjr3DKs+e+dRJ1MYP4cyc4HHvpkvqcn/9nfuyfcvk/vMCNyWqP0HNiku4jQ0LN3bjY6TZzHZeEtFjvgAMsiwFRUTqf5qSpE84ZFa+8BjF502g= Received: from SA9PR13CA0016.namprd13.prod.outlook.com (2603:10b6:806:21::21) by CH2PR12MB3798.namprd12.prod.outlook.com (2603:10b6:610:23::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.22; Thu, 17 Jun 2021 15:09:45 +0000 Received: from SN1NAM02FT0013.eop-nam02.prod.protection.outlook.com (2603:10b6:806:21:cafe::1b) by SA9PR13CA0016.outlook.office365.com (2603:10b6:806:21::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.9 via Frontend Transport; Thu, 17 Jun 2021 15:09:45 +0000 X-MS-Exchange-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 SN1NAM02FT0013.mail.protection.outlook.com (10.97.4.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Thu, 17 Jun 2021 15:09:45 +0000 Received: from MacBook-Air.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 15HF9hS3028621 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 17 Jun 2021 11:09:44 -0400 To: rum@ietf.org References: From: Paul Kyzivat Message-ID: <31f53536-220c-0fb0-5301-ff779d9dcc90@alum.mit.edu> Date: Thu, 17 Jun 2021 11:09:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5339890-418b-49b5-1b13-08d931a1f10a X-MS-TrafficTypeDiagnostic: CH2PR12MB3798: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mxeyrZ/Ottn8pS6MAIbfdoDKtnT5GDmUpxkzn3wu+rjUR6+hjc6+M1OG1Sf0vdGI0vHMcmScrS7SFCVMoNROJDEfHfx0N3xd6087+M8r8xMZ3hZXqX0z2BlMIIKv4riK8LZzaJ0/xX8OZ6e8vNjscuQPhPkGRgw7RHO9cypio+8z/glj9A/yPSh22vRlGS3l0HO/1tMWV6/AcxEf5Cioox1NimWkrFwSFxOoIllbbMRPEMdtzkOKAa0QaUfsYeW12o8EuF7IXXqbkdpKqRACNN0RAsRZHxv2mhO+99Spuobry41Iiz5HT/dTCWKc//ykeQgTDbNvPPI2uwVT9CuMssCZA8bVVunDFBryDGV/BenidnSoygQKDOfhiFDbYtsgUnd6/BMMquNsB6TMGgvsCaV9apEe3p5FQqS4VSa3VCblGoCF82ks2uewkRwn65okLA1Cf0V7jASXfwpL5bSLDYshRPQJ8TxLchZY46G3jPnxvGntVerlFjCTUU/kWK/7yhSXDbT/q62bdYNYkyIoewBqfAhTLx2lIUBI0efJBHd2ADIO7gdJOkR03X15O191RpdrYb82UyBgybBU2jsWuWMepduulwJF3qHSz1mH0alHpp0xe4BsmB2rKuyE+808McwmYDWKM2ppRTVLtbgebj3EiqGaJTnv7Vx2ooxe8tNRyI+9ZkAWGEJrcCjaZ9ng+j4PyuebU+ggPez9xzMzIVktWvRdzhb3RuyUTx/jJB/OgunDhuPHcWjdQsUA9axi7JDosKNBtIKbJLPRo5DigdH3hSvWCYjUu0jpTRESGpY= X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(376002)(136003)(346002)(396003)(39860400002)(46966006)(36840700001)(26005)(478600001)(53546011)(6916009)(5660300002)(316002)(36906005)(2906002)(786003)(186003)(82740400003)(8676002)(70206006)(70586007)(75432002)(31696002)(83380400001)(86362001)(956004)(47076005)(7596003)(82310400003)(336012)(8936002)(2616005)(356005)(66574015)(36860700001)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2021 15:09:45.1203 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a5339890-418b-49b5-1b13-08d931a1f10a 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-AuthSource: SN1NAM02FT0013.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3798 Archived-At: Subject: Re: [Rum] New Version has some changes requested, and not others 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, 17 Jun 2021 15:09:52 -0000 Hello RUMers, I hope with this version we are close to done with RUM. What we need now are careful and thoughtful reviews, especially by those who will be impacted by this spec. (This isn't yet a work group last call review. I'll leave the decision about that to the upcoming meeting.) To people representing VRS providers: Please do a thoughtful review from the provider perspective. While we don't know what the FCC will do, it is entirely possible that it may require that all VRS services be provided via RUM-compliant devices. Please identify anything about this document that would prevent that from happening, or that would render it a poorer offering than what you currently offer. To VRS users: Is there anything you get today using a provider-proprietary device that you couldn't get from a RUM device? Is there any end-user feature that you would like to see that is lacking? Thanks, Paul, as RUM co-chair On 6/14/21 5:41 PM, Brian Rosen wrote: > Thelatest (-05) version > of rum-rue has a > number of changes requested by commenters including: > > * I changed the digest requirement to require RFC8760 and mandate at > least SHA-512 support.  There isn’t any good reason I can think of > to make the mandatory algorithm specified in the configuration. >  Once you implement SHA-anything with any current library, you get > SHA-256 and SHA-512.  Support doesn’t require a change in password, > but it does require an operation to recalculate the digest.  I think > that’s reasonable, and it’s easy to support backwards compatibility > in the server side with both MD5 and SHA-512 with one password and > two digests.  The text does specify that the username/password for > REGISTER must be different from other uses like websites and support > services. > * Added password in the configuration.  It’s optional.  If it’s > returned, the device retains it, and uses it for SIP/STUN/TURN for > subsequent invocations.  If it’s never returned, then the > credentials for the configuration interface are used for SIP/STUN/TURN. > * I added an instance identifier to the configuration data query to > support emergency call location.  I noticed I hadn’t defined the API > Key parameter in the OpenAPI yaml, so I added both parameters in > this version. > > * Support for SIP PUSH (RFC8599) is required if the RUE/Provider > supports mobile devices/clients > > > > I did not make several requested changes.  It will be a chair call, > assisted by Area Directors, to determine if rough consensus exists to > make this changes, and if there is, then I will do them.  As editor, I > am obligated to make the document conform to rough consensus as > determined by chairs, and I will do so to the best of my ability. > > * I left IPv6 required.  We basically don’t do IPv4 work anymore.  It > would be tough for a new document like this to get through the IETF > with only V4.  Both ends are mandated to support V6.  I did add text > using my interpretation of the SIPconnect no-dual-stack-required > text.  It says you can have more than one server specified in the > SRV record, where each server has an A or AAAA record, but not both. >  You can, of course, support dual stack if you want to. > * I left the contact sync as is for now.  Let’s see what rough > consensus is.  I could change from jCard to xCard but that really > does seem backwards for a new spec.  I have reason to believe there > would not be a problem with the US FCC over using jCard.  YMMV. >  Again, I will go with rough consensus on that.  Having done > conversions from one to the other, I know it’s easy.  It’s just > syntax, not semantics. > * I don’t feel all that strongly about dropping VP8 video codec > support, but I’m reluctant to lose WebRTC compatibility.  I feel > much more strongly about retaining support for OPUS.  Again, I will > go with whatever consensus we have.  We deliberately put support for > compatibility with WebRTC in the charter.  A gateway to SIP would be > required to use it.  What we have in our spec is mostly the media > stuff, not the signaling. > * I feel strongly that MWI support is required as there are no other > standards for this functionality and proprietary-only seems wrong to > me.  Again, we’ll have to determine consensus.  There was other list > traffic in support of MWI. > > Brian > > > > > >