From nobody Thu Feb 6 08:15:54 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 536F112006B; Thu, 6 Feb 2020 08:15:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, rum@ietf.org, pkyzivat@alum.mit.edu, rum-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158100575133.20462.11648122928103618463.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 08:15:51 -0800 Archived-At: Subject: [Rum] rum - New Meeting Session Request for IETF 107 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: Thu, 06 Feb 2020 16:15:51 -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: 15 Conflicts to Avoid: Technology Overlap: avtcore dispatch modern sipcore ecrit mmusic quic People who must be present: Adam Roach Brian Rosen Paul Kyzivat Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Feb 12 04:29:15 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 EE20A12007C for ; Wed, 12 Feb 2020 04:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ge--_MFXWpWl for ; Wed, 12 Feb 2020 04:29:11 -0800 (PST) Received: from outbound-ip25a.ess.barracuda.com (outbound-ip25a.ess.barracuda.com [209.222.82.207]) (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 06CAF12007A for ; Wed, 12 Feb 2020 04:29:10 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx8.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 12 Feb 2020 12:29:03 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Feb 2020 04:28:58 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Wed, 12 Feb 2020 04:28:58 -0800 From: James Hamlin To: "rum@ietf.org" Thread-Topic: Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration Thread-Index: AQHV4ZxXCbru0X/CEE6XZxcPNRpdUA== Date: Wed, 12 Feb 2020 12:28:58 +0000 Message-ID: <1581510537826.7963@purple.us> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_15815105378267963purpleus_" MIME-Version: 1.0 X-BESS-ID: 1581510539-893014-9420-30315-1 X-BESS-VER: 2019.1_20200211.1719 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.222204 [from cloudscan9-24.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 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, 12 Feb 2020 12:29:14 -0000 --_000_15815105378267963purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian We do need to be clear, that:- * A VRS user needs an account with a provider before they can use the s= ervice. * Config settings, especially credentials and phone number, are only va= lid for one user account, within the lifetime returned in the JSON object * A user-agent header should be supplied when retrieving configuration = so that configuration can be specific to the RUE Best regards James On 29/01/2020 23:04, Brian Rosen wrote: > The configuration file mechanism needs work. > The current mechanism supports multiple providers in that it allows multi= ple username/passwords. > That=92s probably insufficient. For example, each provider may have thei= r own TURN server. Probably, we want to allow any of the parameters to be = either in the =93top level=94 part of the object, in which case they apply = globally, or in a per-provider part of the object in which case it only app= lies to that provider. > > There is also the issue of cleartext passwords. > > I was thinking about that, but didn=92t really work out a solution. What= I=92m thinking about is that maybe there is a single username/password tha= t unlocks the file, and in the file are per-provider records. The device i= tself manages the encrypt and decrypt of the file. > > I wondered if we could use .well-known, plus that username, to find the f= ile at the default provider=92s website, as listed in the provider file, bu= t 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=92t lint,= and I found two errors that I=92ll get into the next revision. Since we= =92re likely to change that part of the document anyway, that=92s no big de= al. > > Someone also asked about why we specified STUN/TURN in the config, but di= dn=92t mention it anywhere else. It gets into the requirements via the Web= RTC transport spec, which requires ICE, which requires STUN/TURN. So techn= ically, it=92s 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 ha= ve 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 t= o 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 configurati= on 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 dire= ctories. >>> This draft is a work item of the Relay User Machine WG of the IETF. >>> Title : Interoperability Profile for Relay User Equip= ment >>> 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 submi= ssion >>> 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 > > --_000_15815105378267963purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Brian


We do need to be clear, that:-

  • A VRS user needs an account with a provider before they can&n= bsp;use the service.
  • Config settings, especially credentials a= nd phone number, are only valid for one user account, within = ;the lifetime returned in the JSON object
  • A user-agent header shoul= d be supplied when retrieving configuration so that configuration=  can be specific to the RUE

Best regards


James




On 29/01/2020 23:04, Brian Rosen wrote:
> The configuration file mechanism needs work.
> The current mechanism supports multiple providers in that it allows mu= ltiple username/passwords.
> That=92s probably insufficient.  For example, each provider may h= ave their own TURN server.  Probably, we want to allow any of the para= meters to be either in the =93top level=94 part of the object, in which cas= e 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=92t really work out a solution.&nb= sp; What I=92m thinking about is that maybe there is a single username/pass= word 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 th= e file at the default provider=92s 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=92t li= nt, and I found two errors that I=92ll get into the next revision.  Si= nce we=92re likely to change that part of the document anyway, that=92s no = big deal.
>
> Someone also asked about why we specified STUN/TURN in the config, but= didn=92t mention it anywhere else.  It gets into the requirements via= the WebRTC transport spec, which requires ICE, which requires STUN/TURN.&n= bsp; So technically, it=92s okay, but do we want to point that out?
>
> Brian
>
>
>> On Jan 29, 2020, at 5:51 PM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
>>
>> Brian,
>>
>> Thanks for the update. I think I will have a number of questions o= nce have more time for study, but I have one right off:
>>
>> Section 9 says that there is one file for device configuration. Th= at 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 t= here 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. Pe= rhaps it would be sufficient for there to be another entry, for each provid= er, in the provider list file that is used by the RUE to retrieve the confi= guration 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-Dr= afts directories.
>>> This draft is a work item of the Relay User Machine WG of the = IETF.
>>>         Title &nb= sp;         : Interoperability Prof= ile for Relay User Equipment
>>>         Author &n= bsp;        : Brian Rosen
>>>     Filename      = ;  : draft-ietf-rum-rue-02.txt
>>>     Pages      &n= bsp;    : 28
>>>     Date      &nb= sp;     : 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 ("Communicati= ons Assistant") connected via
>>>    a videophone to the deaf/HoH user and an aud= io telephone call to the
>>>    hearing user.  The CA interprets using = sign language on the
>>>    videophone link and voice on the telephone l= ink.  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 d= evices to their service,
>>>    and subsequently to CAs and other dead/HoH u= sers.  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 wo= rk.  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.iet= f.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
>
>


--_000_15815105378267963purpleus_-- From nobody Wed Feb 12 08:50:07 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 E0766120854 for ; Wed, 12 Feb 2020 08:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 Hu7XIdxtqHYt for ; Wed, 12 Feb 2020 08:50:02 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20604.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e88::604]) (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 EEE62120823 for ; Wed, 12 Feb 2020 08:50:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H6sFxsaEgrGAR3CAWhT33ALQTgzYVwWE3d7B8MPymMYzi0ywIVTWupeTAqLhOCdC/GzYvrr1oiJmcjKt21EX/uCQFfgDkGmC+BhceaECmejaLjuBPMk/gGRndsQXf9VOpaDTWAVs8T3lrfkp5Ac/+YzR3OjdatqnAEp/u3RG5gsDu5oPtHQE7xJkZI8hu+HYxuoFIE5EAzD+QH+VT1ALn0sXkXGj6EJO8nd+E1LuSXiBuWUCDIr5X06PJUTnJXEv9eZlsocSoM75ukWQoUOwFLMQXNiqJWBMOUGx417z/knTDI1g++yfXYZzLd6M/VGcchF35WSQiuwfl229Jz1aNw== 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=dw/LQ8QYFLnW+owMRl3ytfdfhY6+9Lt7dSVSFJ8JtHE=; b=HNk5DMLx04jlwU5JOWAjR0469SNw1m6lHZ9SPRvHVh4IJRsKbFsRrL2y57DHXEaUZGwuIspuR7FXRjJJ2nT36qdyejtwuWWIPJl2QVo/E7Z6PDbN0E2OCPyehDQzPswcQqnxEyUgJrfCTv6jSDjYvY0sNhCeMzyNRibIpB35pwbhY62mCzNpHmbfwIfrkitewamZOR21mPzP/wMf9xF0XWfGGrSZ9N41zzJhvCwdqtdtIztYiCBv1ynznmtraK5PJ48PW7SxP3zqYeQmGUEuigdPIQ5ZFvKETPnKrm9QKPzOP48c6rNk9nxTn/lEZVlB882g49qSv6sx8fLecAfKxg== 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=dw/LQ8QYFLnW+owMRl3ytfdfhY6+9Lt7dSVSFJ8JtHE=; b=LsbBiQdarx1PsgRjoyqrRIoB8GySo9Ho9NDO0qAqrIHWQLRuJP3SytHtc+LE/YAsLP9JHz4V94sM1POkL8MgocqRRrInGocNzPcnN56eABcRS+IrssG04fqzlbTR02BrDyh2wjG3Qxwpl06OOe41Y4aFM7pSPs2X7HHDcAbh3qI= Received: from DM3PR12CA0046.namprd12.prod.outlook.com (2603:10b6:0:56::14) by CY4PR12MB1176.namprd12.prod.outlook.com (2603:10b6:903:38::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.27; Wed, 12 Feb 2020 16:50:00 +0000 Received: from CY1NAM02FT046.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::204) by DM3PR12CA0046.outlook.office365.com (2603:10b6:0:56::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.24 via Frontend Transport; Wed, 12 Feb 2020 16:50:00 +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 CY1NAM02FT046.mail.protection.outlook.com (10.152.74.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22 via Frontend Transport; Wed, 12 Feb 2020 16:49:59 +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 01CGnvPG007831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 12 Feb 2020 11:49:58 -0500 To: rum@ietf.org References: <1581510537826.7963@purple.us> From: Paul Kyzivat Message-ID: Date: Wed, 12 Feb 2020 11:49:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <1581510537826.7963@purple.us> Content-Type: text/plain; charset=windows-1252; 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)(39860400002)(346002)(376002)(396003)(136003)(199004)(189003)(53546011)(36906005)(7596002)(966005)(8676002)(316002)(86362001)(186003)(8936002)(786003)(66574012)(336012)(356004)(26826003)(478600001)(2906002)(246002)(31696002)(5660300002)(956004)(31686004)(70586007)(2616005)(6916009)(26005)(70206006)(75432002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR12MB1176; 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: 2ebceb06-130d-4822-d5e5-08d7afdb9931 X-MS-TrafficTypeDiagnostic: CY4PR12MB1176: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0311124FA9 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /uKhiv+YqNbRFHj/TwG5zLyC+nm6eM0jTJl2Gbvz4wIuEQZ6SrJPii9VkCGx92m1C9+Q3wwWBOCF2PL0dw0mlcVJuZpY7pYx1/CLDS/n6XrAH/iKrMPtHFCwxVMgTz5+px0fTRlmDqjH/Y+wlj09oPQpBgJK4fxpyhS+zNjM2Q8as8M3iUqbC4CeGxG7Tw70oqNfSnvU2WsrgXmgSj8zq0CLPu18aLGuGYHSantzq2nW+x+9+90rhN0039/kIIHLXpjk6gBfKS7LZD41x9kvNdx4WlPEOxOJndFdlVjqPYbsdiDwGxCU5vz5ZBQdOzfpB0aybQp7E+4dD+wG/lZt1msoiLZ7Gr9AkKT6tsu6oYhCQtkfbOemwM0RqXrDbjDhww2v7f4aIwd9kZVNdjxjSMQv3hQnFwItllQUcvtfNvfLxmn+qmGRDQCQVKFcaCKZ/RP8le5SuiT77EH0vpKcBxmAUYZU6avma5atGb5pnnkmmWoWNy6U9vRDF6ie454z7dxIolgZJPgG31l5a9wGzg== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2020 16:49:59.7241 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2ebceb06-130d-4822-d5e5-08d7afdb9931 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: CY4PR12MB1176 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, 12 Feb 2020 16:50:06 -0000 Hi James, I'm happy to see you posting here. On 2/12/20 7:28 AM, James Hamlin wrote: > Brian > > > We do need to be clear, that:- > > * A VRS user needs an account with a provider before they can use the > service. With *a* provider. Given that, they can get service from another provider via dial around. And/or they can have accounts with multiple providers. If the RUE supports connections to multiple providers, and also supports one-stage dial-around then the distinction between the two, at least for outgoing calls, will be subtle. > * Config settings, especially credentials and phone number, are only > valid for one user account, within the lifetime returned in the JSON > object > * A user-agent header should be supplied when retrieving configuration > so that configuration can be specific to the RUE Agree. The point I was trying to make is that each provider will want to maintain the config information for its own account. If the user has accounts with multiple providers, then the RUE needs to fetch the config information for each of them from the corresponding provider. Separately the RUE will need common config information - notably which providers user has accounts with. I'm imagining that the RUE will hold that locally. If the user has multiple RUEs then it might be helpful to have some common place to store that common config information, but I don't know who would host it. Thanks, Paul > Best regards > > > James > > > > > On 29/01/2020 23:04, 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. > > > > 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 Mon Feb 17 18:53:07 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 51C0B120866 for ; Mon, 17 Feb 2020 16:08:06 -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 4nkpS86Cdo0r for ; Mon, 17 Feb 2020 16:08:04 -0800 (PST) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 1CB1812002E for ; Mon, 17 Feb 2020 16:08:04 -0800 (PST) Received: by mail-yw1-xc34.google.com with SMTP id 10so8645596ywv.5 for ; Mon, 17 Feb 2020 16:08:04 -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=4MC59faEMz2Ys0s9xqMO9626IrPeDsRfnTiwx8CLuJg=; b=yV54dJdOhchgx+xotKK8acb1YJ1baISCW6XJCkrbwLY6pBmk/oBcmb13+Lui1ouITL /EzryKXkF0sKEDB5sWoDrVYyajcta9+eCViQQK698UBgZ3SGuEy+vXZTcXZoTBl/LzQh I3vcQy8lhjYn87IhpVmJostq6uP3JCWJw3+A3C4dcmBzMQz5vbcc4kM+MsF3dzC44O3h GSajk0cxuikgGW03yoZJpvWqWDAaF1Jx2j1yWcEugB5wiuWOtPbHQw+Vsf43eBjWZJJL h4DMDKMFHhzaa/RCck2xuPm6CyrP05+3zKYL+/niq16udoIsvtX8KhCr+t0KVud87jIb Q2kQ== 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=4MC59faEMz2Ys0s9xqMO9626IrPeDsRfnTiwx8CLuJg=; b=lq5SHp5BFRdV5NvyXtow5mlpFD8KVFgFMsGTcSOzM2xABagDC9olbOD04qMDUZEroC NN2Tme9/GnW/pY5S/MjG/w37cBJJMtqG8Mw5Kh51RunmhOOyi6Vm79OF3n9bHxOhdyY0 6ZrNF44OATE23jVYsssxmiPPhKNKie+cG7cLljwXRVr6/8ds+VU+0QAtgTobEhWeQL/w 902slSt7Ldc4a5si9Jo8kqUNM+AhWmLsunevcLYBIYEb3A8kwK5Eqcf3BB7fhNe/bQ2q i35+AMMJCRoU/wt9bdS7h8Dh1oTYkUKUkLkgaTWG4J1IotG3yZCmIJ5KUDR5QY5UEp7v YkmQ== X-Gm-Message-State: APjAAAWimXZSBkVnxSIhc+kv1AxwPznB/FJ8EXtkJQJvt4caJX8jmevQ 9F3YcSwrZhZSeD0sI18y9bU6SA3EfPM= X-Google-Smtp-Source: APXvYqyh0Zn7ny2iHRRG5JZv7Fvc+y6MEruhA/Xzh8NBZaKU/srOhih4JYayrtrovcDXKAxmCfcFPw== X-Received: by 2002:a81:11d7:: with SMTP id 206mr15861189ywr.150.1581984482942; Mon, 17 Feb 2020 16:08:02 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id o4sm971455ywd.5.2020.02.17.16.08.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2020 16:08:02 -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: Mon, 17 Feb 2020 19:08:00 -0500 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net> 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 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: Tue, 18 Feb 2020 00:08:06 -0000 Inline > On Jan 30, 2020, at 1:00 PM, Paul Kyzivat = wrote: >=20 > Here are some further comments on -02: >=20 > 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). You might be right about Outbound, but only in the sense that the = providers don=E2=80=99t have to implement it at all, but if they do, = then they have to do what 5656 says. Events is sort of the same way, depending on what the final text on MWI = says. Geoloc isn=E2=80=99t: the provider must accept and pass Geoloc to = maintain 6881 conformance. There are some differences, but I=E2=80=99d prefer to use =E2=80=9CUAC = and =E2=80=9CUAS=E2=80=9D as the terms. >=20 > Section 5.2.1 now says: >=20 > The all outbound calls MUST be routed through an outbound proxy if > configured. >=20 > (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.) Yes, but doesn=E2=80=99t the text read correctly? >=20 > Section 5.2.3 says: >=20 > 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". >=20 > This new purpose parameter needs to be registered with IANA. It = currently isn't mentioned in section 11. Yes, need to do that. >=20 > Section 5.2.5 says: >=20 > The implementations comply with [RFC6881] for handling of emergency > calls. >=20 > 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.) Missing the MUST. It has to be normative (among other things, NG9-1-1 = in the US requires it). >=20 > 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. I=E2=80=99ll change to UAC/UAS >=20 > Section 5.5 and elsewhere use the following construction: >=20 > Implementations MUST conform to ... with the understanding that ... >=20 > 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. Could you suggest language. I agree with you. >=20 > Section 6.3: >=20 > 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. >=20 > 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? I think those questions are more a regulator issue. UACs must offer = VP8. UASs must support VP8 if both ends support VP8. I don=E2=80=99t = think this doc should mandate what a VideoMail server does, because = that=E2=80=99s outside the scope (VM servers may or may not conform to = this doc). =20 Language suggestions welcome! >=20 > Section 8: >=20 > 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. Yeah, although I have a pretty hard time not mandating MWI. I really = don=E2=80=99t think there is a reasonable way to build a client without = supporting MWI, since there is no other interface to support the = function. >=20 > Section 9.1: >=20 > This makes it optional for a RUE to make the choice of provider = available to the user. Is that what we want? >=20 Hmmm. Is that a UI issue, and thus beyond scope, or an interface issue = and in scope? > Section 9.3: >=20 > 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.\\ Yeah, I=E2=80=99m pretty heavily dealing with this in other venues. I = think we want json schemas. I=E2=80=99ll do that next rev. >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Feb 17 18:53:14 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 4B47C120866 for ; Mon, 17 Feb 2020 16:12:44 -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 gvtgjsMF_Dn3 for ; Mon, 17 Feb 2020 16:12:42 -0800 (PST) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 158A012002E for ; Mon, 17 Feb 2020 16:12:42 -0800 (PST) Received: by mail-yw1-xc30.google.com with SMTP id b81so8644254ywe.9 for ; Mon, 17 Feb 2020 16:12:42 -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=FDNCpIghTlMXxatT33vwDmZaqVFhQNJej/a2egnceMo=; b=kNT+0Dqj5PBwMcSnyvC4SWgK91vSo7zFKrsrEI96Yu+iB6Y6G1di+q/V8BltVhBDb5 34lou7lTRqzMsrOJnpUyTRY8lw2I66WKAItmzlHCEU6lvhauZ7kZ70TS6/3d67kdTKLw 3s2FAVIHcfiuz8m42p4ATc1ImXZo5psAuezEH3YefAz53MHqFRRPq89gax0ybjS+a5+o TxmSwk8x1bvghCQqXokBcSAIxvf32wkTbTIjuPMBq1Sl7f7Fm7JMdhI8ryx3beuluU/c p2wO4434HAeLiK5ftO6lrW9KFUKfXxXC5h+DNLwIoU52N+vtShOmQjdxEAk86hePGXoZ 9vAA== 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=FDNCpIghTlMXxatT33vwDmZaqVFhQNJej/a2egnceMo=; b=CKDftDhFz9Q4REwNqTP6DsSyNy3PPeI9D4jOESnHYOpk78mqyd1FFybxTH+26pYc0p exjkudsF+uMGHC+aZwNS19lIYkmX2iNc2hosc+5upFUU4D1XBeP30Pn6k5ApQJA9j6vt CHepWoIF69UDXraMgok4d9uyKRTImJII4rcL51lj0ZhKf5QcX9+EPA04WVR2rPQPMWMo PVsRQJOHisWexO6Y/wqgaaDXCbioQZZ4n1YqRn/Nfgf/1TlXiJcOKQtWOpkljrPY2z4h GxAwKRHxZMMfnMOgZ6BmS2qrtuR1W5GVfDd1Z/wY3hXY5cfouJVHTCQjZ0udCSI8PKLM my/g== X-Gm-Message-State: APjAAAXdD2cezr5EEqPSG06DAaol1JrB04sjDuEISj2moQCxSVV4fBeq u0P8lNRwbABggdCAmbXG5NPuTrIM3bc= X-Google-Smtp-Source: APXvYqzkVQ7cZqWQaLfwa4n9IOrP/iqfLHbk+174Bx01x9weFmKhfWTbao+pmx4ghWv2Td2giiSzwg== X-Received: by 2002:a81:8405:: with SMTP id u5mr14925965ywf.93.1581984760961; Mon, 17 Feb 2020 16:12:40 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id t3sm1041457ywi.18.2020.02.17.16.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2020 16:12:40 -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: Mon, 17 Feb 2020 19:12:36 -0500 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C43EA61-D478-41D5-8212-C5D783F79DAE@brianrosen.net> References: <1581510537826.7963@purple.us> 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: Tue, 18 Feb 2020 00:12:44 -0000 > On Feb 12, 2020, at 11:49 AM, Paul Kyzivat = wrote: >=20 > Hi James, >=20 > I'm happy to see you posting here. Me too! >=20 > On 2/12/20 7:28 AM, James Hamlin wrote: >> Brian >> We do need to be clear, that:- >> * A VRS user needs an account with a provider before they can use = the >> service. >=20 > With *a* provider. Given that, they can get service from another = provider via dial around. And/or they can have accounts with multiple = providers. >=20 > If the RUE supports connections to multiple providers, and also = supports one-stage dial-around then the distinction between the two, at = least for outgoing calls, will be subtle. My thoughts on this are that we require support for 3261 authentication = on REGISTER and you need to be registered to place or receive calls. A = dial around call isn=E2=80=99t placed directly =3D it=E2=80=99s through = the default provider. That means I don=E2=80=99t think we need normative language (beyond = support for 3261) to get what James is asking for. >=20 >> * Config settings, especially credentials and phone number, are only >> valid for one user account, within the lifetime returned in the = JSON >> object >> * A user-agent header should be supplied when retrieving = configuration >> so that configuration can be specific to the RUE >=20 > Agree. >=20 > The point I was trying to make is that each provider will want to = maintain the config information for its own account. If the user has = accounts with multiple providers, then the RUE needs to fetch the config = information for each of them from the corresponding provider. >=20 > Separately the RUE will need common config information - notably which = providers user has accounts with. I'm imagining that the RUE will hold = that locally. If the user has multiple RUEs then it might be helpful to = have some common place to store that common config information, but I = don't know who would host it.\ We need some ideas on exactly how to do this. I=E2=80=99ll start a = separate thread on that. >=20 > Thanks, > Paul >=20 >> Best regards >> James >> On 29/01/2020 23:04, Brian Rosen wrote: >> > 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: >> >> >> >> 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=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/ >> >> >> >> -- >> >> Rum mailing list >> >> Rum@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rum >> > >> > >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Feb 19 11:24:22 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 4DB33120045 for ; Wed, 19 Feb 2020 11:24:20 -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 bqtby2yLJGpW for ; Wed, 19 Feb 2020 11:24:17 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2043.outbound.protection.outlook.com [40.107.244.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 61BCC120088 for ; Wed, 19 Feb 2020 11:24:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U1icxEaD1zoOaCYQjt6wxvK0Bh6PAKnAzG72DWyh+nVrv0NZTkDZXgUkEVwpnMeb0CbLkhVHlzhxrivsSOd2mL2eW7j7LrhrOruc6wnBoB+3af7kJiiu0JG+QU+yTwWU9oJ6vqWAQHcFC+FVPVyWgTfYt8GbARJVobYgGnUyDp1vPaM5wGuyFUP9GDPNPWWvnXas+rXV7D9my2d4b+oIJL5zWlWm1yWJlnLr7ramBxMuV/1Guw/99vfszTQefxBdJzgOSjg6Asl2590nGRht9SSdv+bLq3LEbRhVLIsBMl7qIbVt0Y5NVMEcC9eB4904kix1sXgYh3luZlxNo0l8vg== 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=ZY/kVxf07qH4+j9lgqJWFfcqfqO64NdBS09eBZvH6RQ=; b=d/kR2GVfBH19W1VmkoG2fEjIbmgfwuO8ALyqiqT+m7dPYrYY0ghHIn5RhmuXce/UF6eVDwXcRL4AjAIRqdmJWvtpBlwz+N/4ckFJZpBraIyfTBsGY/rPj+VRfX/uo8lJaR/yqX5+sutZwsFVMa7tbC819uD0IopUiaEwANYS3p7knyjwn1y4p2BVEL3J8nWuyOSVupQ30KlVteUq53orvhSDhO7OikiaBj94bSjKDhkJOLuKIHptX+7UYmbACc6ItpagwVBSq5gVBPQYto3nkbLmrXEEHx8d4XPKRUqH2Zj7Dh1flg141s+oYodRpVNu+bjyS031r024eQuxRj4u+A== 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=ZY/kVxf07qH4+j9lgqJWFfcqfqO64NdBS09eBZvH6RQ=; b=VJOueNYUZ/BHDobkoFSt/gsa031DD35WY8gK0hGKSPLILQWhpkqhLgY+36ZQqlBXVG5bXwRQH3TOW+52abyC5yjGG5cM3gc2UbQX2nugtvsqaF9FEgiPvhiIIPqtA6pXfo9uyWU7bUw0gUWZr1OCYkcANUZfqTJxudkI6nRCDI8= Received: from DM3PR12CA0064.namprd12.prod.outlook.com (2603:10b6:0:56::32) by BYAPR12MB3253.namprd12.prod.outlook.com (2603:10b6:a03:12f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Wed, 19 Feb 2020 19:24:16 +0000 Received: from SN1NAM02FT026.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::208) by DM3PR12CA0064.outlook.office365.com (2603:10b6:0:56::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17 via Frontend Transport; Wed, 19 Feb 2020 19:24:15 +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 SN1NAM02FT026.mail.protection.outlook.com (10.152.72.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22 via Frontend Transport; Wed, 19 Feb 2020 19:24:13 +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 01JJOBf1030732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Feb 2020 14:24:12 -0500 To: Brian Rosen Cc: rum@ietf.org References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Wed, 19 Feb 2020 14:24:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net> 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)(39860400002)(396003)(136003)(346002)(376002)(189003)(199004)(36906005)(31686004)(26826003)(956004)(53546011)(316002)(786003)(336012)(2616005)(2906002)(478600001)(186003)(26005)(356004)(86362001)(6916009)(8936002)(8676002)(246002)(4326008)(70586007)(70206006)(31696002)(7596002)(75432002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR12MB3253; 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: 96129e79-e551-4f1d-3d88-08d7b5714dfd X-MS-TrafficTypeDiagnostic: BYAPR12MB3253: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0318501FAE X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Y2m/4pbSKt8k9yhcbUJEOtgMcJ9nV+4b0ueWAXrtBSuDwwQO/tLWrqFo8hzMp0ly+fZ1HKIRCBq4fTIz1Ijw9R93HmmtBzGDGbSwKmqYDOF2m362JRFrWFTxE27LVU4NqmV9GQWnZL0n8dnbZOazaEkMvQzWJqG7bfce6H8UqAbB/LNHIz7ZssJXHPU2JOXneanh5il9bnY6mamBOmT1IVof0ey/iM65K5kAx1FcVdvhamhHGi0sx8b+JWp4/InpUgBZx6sZzKHqHm2Gu46uoCkZbp/mHhHgo5uxrmJr1MHMpHspINUWwmhFcsmxwPN4DJcEO0BwoPudEHqAYhfcwd7ZlWvOd4a8X7FkcutL1JzEbqrA2uKuYWB78iJaVw/tXCEW16RrR4FNFnKHCx8P97GPKdkJDbza1W3bmIyCjDyRgFB+I/iyulqiM3iGI2FB X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2020 19:24:13.7035 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 96129e79-e551-4f1d-3d88-08d7b5714dfd 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: BYAPR12MB3253 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: Wed, 19 Feb 2020 19:24:20 -0000 Brian, Followups inline. On 2/17/20 7:08 PM, Brian Rosen wrote: > Inline > >> On Jan 30, 2020, at 1:00 PM, Paul Kyzivat wrote: >> >> 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). > You might be right about Outbound, but only in the sense that the providers don’t have to implement it at all, but if they do, then they have to do what 5656 says. > Events is sort of the same way, depending on what the final text on MWI says. > Geoloc isn’t: the provider must accept and pass Geoloc to maintain 6881 conformance. My point in general though is that most of these protocols specify differing behavior on the two ends of a connection. Sometimes this is UAC vs. UAS, but not always. So at least I think we need to profile what part each end must support. For instance: - when outbound is in use, the roles of the RUE and the provider are clearly distinct. E.g. the RUE is responsible for setting of the connections to the server, and keeping them up as long as it wants the possibility of receiving a call. - for MWI the RUE is always the subscriber and the provider is always the publisher. - for location information I should probably have called out RFC6881 rather than RC6442. The RUE will be the one including geoloc info, and the provider acting on it. I don't think there is any requirement or expectation that geoloc info flows from the provider to the RUE. > There are some differences, but I’d prefer to use “UAC and “UAS” as the terms. Rarely is that the proper distinction for this. E.g., for MWI the RUE is the UAC for subscriptions, but is UAS for the notifications. >> >> 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.) > Yes, but doesn’t the text read correctly? IMO the old way was right. ("The RUE MUST route all calls through the outbound proxy ...") This of course depends on what you mean by an outbound call. A call *to* a particular RUE in inbound from the RUE perspective, but what is it from the perspective of the interpreter at the provider that is initiating it? >> 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. > Yes, need to do that. OK >> 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.) > Missing the MUST. It has to be normative (among other things, NG9-1-1 in the US requires it). OK >> 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. > I’ll change to UAC/UAS I don't think that works. UAC pertains only to a particular message. Both RUE and provider take both roles at various times. IIUC Additional Data is only ever sent in requests, not responses, so of course it will be a UAC that is sending. What is really important here is that it is the RUE that is sending the Additional Data. >> 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. > Could you suggest language. I agree with you. There are three usages of this language, in 5.5, 6.1, and 6.6. These refer respectively to rtcweb-transports, rtcweb-rtp-usage, rtcweb-jsep. I started looking at rtcweb-transports to see how to rewrite it. It isn't written in a way that makes it easy to adopt for our needs. I'm not sure it is possible without violating some of its normative statements. I think we may need to go through it almost line by line to see if we can make it work. I didn't look at the others in detail yet. I think this may be a significant effort. We may find that we simply have to copy and modify some text with these, and discuss how that will facilitate interop with rtcweb. We need to start a separate thread focused on this. >> 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? > I think those questions are more a regulator issue. UACs must offer VP8. UASs must support VP8 if both ends support VP8. I don’t think this doc should mandate what a VideoMail server does, because that’s outside the scope (VM servers may or may not conform to this doc). > > Language suggestions welcome! IIUC you are suggesting that H.264 is MTI by both provider and RUE. Beyond that it isn't clear. We could just leave it at that, and leave it to the FCC to mandate VP8 if they want. Or, we could mandate VP8 support by providers on the RUE interface without requiring that RUEs support it. That would allow new RUE implementations that support VP8, but would still allow RUE implementations without it so that old devices can be supported. (In particular, the potential upgrading of existing provider supplied equipment.) This requires further discussion of what we are trying to accomplish. >> 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. > Yeah, although I have a pretty hard time not mandating MWI. I really don’t think there is a reasonable way to build a client without supporting MWI, since there is no other interface to support the function. IIUC (I might not) at least some providers now provide a non-SIP mechanism for retrieving video mail. (A web interface?) However, that might not be accessible to users with a conforming RUE. Potentially they could simply say they don't support receiving video mail via SIP. In the past we had some language that said if the RUE spec makes a feature optional, they a provider MUST provide it if they have a comparable proprietary feature. We can check, but I suspect that *every* provider has video mail. If so, they making this MTI makes sense to me. >> 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? >> > Hmmm. Is that a UI issue, and thus beyond scope, or an interface issue and in scope? We can specify the need to provide the feature without specifying what it looks like in the UI. This is analogous the requiring the support of MWI. It seems likely to me that the providers will provide a RUE implementation that runs on some of their already deployed hardware. They most likely won't want to enable it to choose another provider. We need to decide if that is ok or not. Or we can leave it to the FCC to decide. >> 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.\\ > Yeah, I’m pretty heavily dealing with this in other venues. I think we want json schemas. I’ll do that next rev. Sounds like you are more up to speed than I am. Thanks, Paul From nobody Mon Feb 24 09:53:23 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 92F263A0FE3 for ; Mon, 24 Feb 2020 09:53:21 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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 VzODJlGZbiUD for ; Mon, 24 Feb 2020 09:53:18 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 AB7213A0FD6 for ; Mon, 24 Feb 2020 09:53:17 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id b81so5585513ywe.9 for ; Mon, 24 Feb 2020 09:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QLnGDCqD9kLMZLJrONux/kAOjA8ILWKyISslSqrKFjQ=; b=HlvmQ1SU4EF42eSAMsj3tRU7kxrtP8d1mlZr4/3Z9zJVZmEqdHmbN2ApH5FCoMMKE8 rcLpPRO2qj3nKfNDmqel9xBXVOd83rA0Qw/PmU+jKA3e0zVcKvgMIb4v/3sbxQGTrvxX kOaKjgFvJ11vY6LcOTrrDPy+JD5HZhfHnxR4dhAzKxUtASqm14+zReccXdo3KHQfnBia iN4CtSTR/jyox7nBtE/Sw7ED0oeDCXNrh918Yx7B/XWGVj5a2fVSqfiC9WY2HIAaiIHc tZj9eEl77w3BseUCB/9oSrMW+f3tWg47dLoVl9DBp8t+y9+P61PoW1iiu8ZTswvbWbr9 XgNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QLnGDCqD9kLMZLJrONux/kAOjA8ILWKyISslSqrKFjQ=; b=Fgd6ACNg62CV3C8DWA7JjoWzNvXt5YaaBCF50eXOAxbr9D52NHiMGwIIq+C/XGMESl uBTBOEBnykSIjaybHOeqUEueM2KvMIhs2ofXsYbYT8xg+AAabONsq29SwMbmh3SmXcBG cMS9RqCm4AiTgUOdNksKFC50xXzEAC6RMPrvi/D39ijiPri4JQCTU2++WJh2Gyu7Gw3y iQGQLM8pO9nm74HLfJUmlhYIJRvtYw6u1bq4r+OcY5G9wshgtxr0plMpLRcY7jBFXSKa DwKlXrOAJmK4TBtr6TT2DsbtgmjfUJFnCHCald3ZEpccrBpftutAMEw+mRIkrboRq6Et 6TxQ== X-Gm-Message-State: APjAAAUQs6sDkCr+P9NSULcTS6j3J3SLj2yLjfgwzInhWpxr0T5ANCqR chcU8g38NVQHu934itTbhNaQHVR3Daw= X-Google-Smtp-Source: APXvYqxhh1ZcdXFhuDMhPUrZAqdymyZpbnlx2P7r+1QmS4J3SB8gQ/pybzes8JklYuHRQUUMQA6FFg== X-Received: by 2002:a81:6388:: with SMTP id x130mr42194248ywb.252.1582566796602; Mon, 24 Feb 2020 09:53:16 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id s130sm5387027ywg.11.2020.02.24.09.53.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2020 09:53:16 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3DA32267-0444-46D7-82FB-D64D69052592" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 24 Feb 2020 12:53:09 -0500 In-Reply-To: Cc: rum@ietf.org To: Paul Kyzivat References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: Mon, 24 Feb 2020 17:53:22 -0000 --Apple-Mail=_3DA32267-0444-46D7-82FB-D64D69052592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline > On Feb 19, 2020, at 2:24 PM, Paul Kyzivat = wrote: >=20 > Brian, >=20 > Followups inline. >=20 > On 2/17/20 7:08 PM, Brian Rosen wrote: >> Inline >>> On Jan 30, 2020, at 1:00 PM, Paul Kyzivat = wrote: >>>=20 >>> Here are some further comments on -02: >>>=20 >>> 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). >> You might be right about Outbound, but only in the sense that the = providers don=E2=80=99t have to implement it at all, but if they do, = then they have to do what 5656 says. >> Events is sort of the same way, depending on what the final text on = MWI says. >> Geoloc isn=E2=80=99t: the provider must accept and pass Geoloc to = maintain 6881 conformance. >=20 > My point in general though is that most of these protocols specify = differing behavior on the two ends of a connection. Sometimes this is = UAC vs. UAS, but not always. So at least I think we need to profile what = part each end must support. >=20 > For instance: >=20 > - when outbound is in use, the roles of the RUE and the provider are = clearly distinct. E.g. the RUE is responsible for setting of the = connections to the server, and keeping them up as long as it wants the = possibility of receiving a call. >=20 > - for MWI the RUE is always the subscriber and the provider is always = the publisher. >=20 > - for location information I should probably have called out RFC6881 = rather than RC6442. The RUE will be the one including geoloc info, and = the provider acting on it. I don't think there is any requirement or = expectation that geoloc info flows from the provider to the RUE. But ISTM that all we need do it say that conformance to the appropriate = standards is required. Those standards specify what each end has to do. = Our document doesn=E2=80=99t need to specify. >=20 >> There are some differences, but I=E2=80=99d prefer to use =E2=80=9CUAC = and =E2=80=9CUAS=E2=80=9D as the terms. >=20 > Rarely is that the proper distinction for this. E.g., for MWI the RUE = is the UAC for subscriptions, but is UAS for the notifications. I think that is one of the few exceptions. We can use =E2=80=9Cclient=E2=80= =9D and =E2=80=9Cserver=E2=80=9D when we need to. >=20 >>>=20 >>> Section 5.2.1 now says: >>>=20 >>> The all outbound calls MUST be routed through an outbound proxy if >>> configured. >>>=20 >>> (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.) >> Yes, but doesn=E2=80=99t the text read correctly? >=20 > IMO the old way was right. ("The RUE MUST route all calls through the = outbound proxy ...") >=20 > This of course depends on what you mean by an outbound call. A call = *to* a particular RUE in inbound from the RUE perspective, but what is = it from the perspective of the interpreter at the provider that is = initiating it? I don=E2=80=99t think in this document we are concerned about what the = interpreter is sitting in front of. I=E2=80=99d like it to be a RUE, = but it doesn=E2=80=99t have to be (unless the regulator says it has to = be). All that we are concerned with here is the interface between the = RUE and the rest of the ecosystem, which will have providers, other RUE = devices and some non-RUE devices we want to be backwards compatible = with. >=20 >>> Section 5.2.3 says: >>>=20 >>> 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". >>>=20 >>> This new purpose parameter needs to be registered with IANA. It = currently isn't mentioned in section 11. >> Yes, need to do that. >=20 > OK >=20 >>> Section 5.2.5 says: >>>=20 >>> The implementations comply with [RFC6881] for handling of = emergency >>> calls. >>>=20 >>> 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.) >> Missing the MUST. It has to be normative (among other things, = NG9-1-1 in the US requires it). >=20 > OK >=20 >>> 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. >> I=E2=80=99ll change to UAC/UAS >=20 > I don't think that works. UAC pertains only to a particular message. = Both RUE and provider take both roles at various times. IIUC Additional = Data is only ever sent in requests, not responses, so of course it will = be a UAC that is sending. What is really important here is that it is = the RUE that is sending the Additional Data. Actually, the provider is most often the entity that sends Additional = Data. The RUE might also, but the provider always does so. >=20 >>> Section 5.5 and elsewhere use the following construction: >>>=20 >>> Implementations MUST conform to ... with the understanding that = ... >>>=20 >>> 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. >> Could you suggest language. I agree with you. >=20 > There are three usages of this language, in 5.5, 6.1, and 6.6. These = refer respectively to rtcweb-transports, rtcweb-rtp-usage, rtcweb-jsep. >=20 > I started looking at rtcweb-transports to see how to rewrite it. It = isn't written in a way that makes it easy to adopt for our needs. I'm = not sure it is possible without violating some of its normative = statements. I think we may need to go through it almost line by line to = see if we can make it work. >=20 > I didn't look at the others in detail yet. >=20 > I think this may be a significant effort. We may find that we simply = have to copy and modify some text with these, and discuss how that will = facilitate interop with rtcweb. >=20 > We need to start a separate thread focused on this. Okay >=20 >>> Section 6.3: >>>=20 >>> 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. >>>=20 >>> 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? >> I think those questions are more a regulator issue. UACs must offer = VP8. UASs must support VP8 if both ends support VP8. I don=E2=80=99t = think this doc should mandate what a VideoMail server does, because = that=E2=80=99s outside the scope (VM servers may or may not conform to = this doc). >> Language suggestions welcome! >=20 > IIUC you are suggesting that H.264 is MTI by both provider and RUE. = Beyond that it isn't clear. I think a conforming interface has to support 264, and VP8 is optional.=20= >=20 > We could just leave it at that, and leave it to the FCC to mandate VP8 = if they want. Adam suggested that given the realities, H.264 as MTI is acceptable. = That=E2=80=99s okay with me. >=20 > Or, we could mandate VP8 support by providers on the RUE interface = without requiring that RUEs support it. That would allow new RUE = implementations that support VP8, but would still allow RUE = implementations without it so that old devices can be supported. (In = particular, the potential upgrading of existing provider supplied = equipment.) =E2=80=9CBy the providers=E2=80=9D could be interpreted in several ways. = One is that the interface supports VP8. I certainly hope that=E2=80=99s = a requirement. Another is that an endpoint that the provider has, = specifically, the CA=E2=80=99s workstation, or the videomail endpoint, = supports VP8. I wouldn=E2=80=99t have any text in our document that = would require that. As a practical matter, what that means is that if = two RUE devices on different providers negotiated VP8, that it would = work, but if we looked at the offer from, say, the CA, we may or may not = see VP8. Does that make sense? Is that okay? >=20 > This requires further discussion of what we are trying to accomplish. >=20 >>> Section 8: >>>=20 >>> 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. >> Yeah, although I have a pretty hard time not mandating MWI. I really = don=E2=80=99t think there is a reasonable way to build a client without = supporting MWI, since there is no other interface to support the = function. >=20 > IIUC (I might not) at least some providers now provide a non-SIP = mechanism for retrieving video mail. (A web interface?) A web interface is fine, and I=E2=80=99m not arguing for mandating any = particular way to retrieve VM, but I think it=E2=80=99s pretty important = that the UI of a RUE be able to show that there is VM waiting, and I = think MWI is the only standards based way to provide an interface that = would let it do that. >=20 > However, that might not be accessible to users with a conforming RUE. = Potentially they could simply say they don't support receiving video = mail via SIP. In the past we had some language that said if the RUE spec = makes a feature optional, they a provider MUST provide it if they have a = comparable proprietary feature. Yeah, I don=E2=80=99t want to see that kind of language in an IETF doc. = The regulator could say that, not us. >=20 > We can check, but I suspect that *every* provider has video mail. If = so, they making this MTI makes sense to me. >=20 >>> Section 9.1: >>>=20 >>> This makes it optional for a RUE to make the choice of provider = available to the user. Is that what we want? >>>=20 >> Hmmm. Is that a UI issue, and thus beyond scope, or an interface = issue and in scope? >=20 > We can specify the need to provide the feature without specifying what = it looks like in the UI. This is analogous the requiring the support of = MWI. >=20 > It seems likely to me that the providers will provide a RUE = implementation that runs on some of their already deployed hardware. = They most likely won't want to enable it to choose another provider. We = need to decide if that is ok or not. Or we can leave it to the FCC to = decide. I think the interface (in this case, I think this is a json object in a = file) has to support it. I don=E2=80=99t know if we need to go any = farther. >=20 >>> Section 9.3: >>>=20 >>> 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.\\ >> Yeah, I=E2=80=99m pretty heavily dealing with this in other venues. = I think we want json schemas. I=E2=80=99ll do that next rev. >=20 > Sounds like you are more up to speed than I am. Yeah, probably >=20 > Thanks, > Paul --Apple-Mail=_3DA32267-0444-46D7-82FB-D64D69052592 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline

On Feb 19, 2020, at 2:24 PM, = Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Brian,

Followups inline.

On 2/17/20 7:08 PM, Brian Rosen = wrote:
Inline
On = Jan 30, 2020, at 1:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

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).
You might be right about Outbound, but only in = the sense that the providers don=E2=80=99t have to implement it at all, = but if they do, then they have to do what 5656 says.
Events = is sort of the same way, depending on what the final text on MWI = says.
Geoloc isn=E2=80=99t: the provider must accept and = pass Geoloc to maintain 6881 conformance.

My point in general though is = that most of these protocols specify differing behavior on the two ends = of a connection. Sometimes this is UAC vs. UAS, but not always. So at = least I think we need to profile what part each end must = support.

For = instance:

- when = outbound is in use, the roles of the RUE and the provider are clearly = distinct. E.g. the RUE is responsible for setting of the connections to = the server, and keeping them up as long as it wants the possibility of = receiving a call.

- for MWI the RUE is always the subscriber and the provider = is always the publisher.

- for location information I should probably have called out = RFC6881 rather than RC6442. The RUE will be the one including geoloc = info, and the provider acting on it. I don't think there is any = requirement or expectation that geoloc info flows from the provider to = the RUE.
But ISTM that all we need do it say = that conformance to the appropriate standards is required.  Those = standards specify what each end has to do.  Our document doesn=E2=80=99= t need to specify.


There are some differences, but I=E2=80= =99d prefer to use =E2=80=9CUAC and =E2=80=9CUAS=E2=80=9D as the = terms.

Rarely is that the proper distinction for this. E.g., for MWI = the RUE is the UAC for subscriptions, but is UAS for the = notifications.
I think that is = one of the few exceptions.  We can use =E2=80=9Cclient=E2=80=9D and = =E2=80=9Cserver=E2=80=9D when we need to.



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.)
Yes, but = doesn=E2=80=99t the text read correctly?

IMO the old way was right. ("The = RUE MUST route all calls through the outbound proxy ...")

This of course depends on what = you mean by an outbound call. A call *to* a particular RUE in inbound = from the RUE perspective, but what is it from the perspective of the = interpreter at the provider that is initiating it?
I don=E2=80=99t think in this document we = are concerned about what the interpreter is sitting in front of. =  I=E2=80=99d like it to be a RUE, but it doesn=E2=80=99t have to be = (unless the regulator says it has to be).  All that we are = concerned with here is the interface between the RUE and the rest of the = ecosystem, which will have providers, other RUE devices and some non-RUE = devices we want to be backwards compatible with.

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.
Yes, need to do that.

OK

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.)
Missing the MUST.  It = has to be normative (among other things, NG9-1-1 in the US requires = it).

OK

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.
I=E2=80=99ll change to UAC/UAS

I don't think that works. UAC pertains only to a particular = message. Both RUE and provider take both roles at various times. IIUC = Additional Data is only ever sent in requests, not responses, so of = course it will be a UAC that is sending. What is really important here = is that it is the RUE that is sending the Additional Data.
Actually, the provider is most often the = entity that sends Additional Data.  The RUE might also, but the = provider always does so.


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.
Could you suggest language. =  I agree with you.

There are three usages of this = language, in 5.5, 6.1, and 6.6. These refer respectively to = rtcweb-transports, rtcweb-rtp-usage, rtcweb-jsep.

I started looking at = rtcweb-transports to see how to rewrite it. It isn't written in a way = that makes it easy to adopt for our needs. I'm not sure it is possible = without violating some of its normative statements. I think we may need = to go through it almost line by line to see if we can make it = work.

I didn't look = at the others in detail yet.

I think this may be a significant effort. We may find that we = simply have to copy and modify some text with these, and discuss how = that will facilitate interop with rtcweb.

We need to start a separate thread focused on this.
Okay


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?
I think those questions are more a = regulator issue.  UACs must offer VP8.  UASs must support VP8 = if both ends support VP8.  I don=E2=80=99t think this doc should = mandate what a VideoMail server does, because that=E2=80=99s outside the = scope (VM servers may or may not conform to this doc).
Language suggestions welcome!

IIUC you are suggesting that = H.264 is MTI by both provider and RUE. Beyond that it isn't = clear.
I think a conforming interface has = to support 264, and VP8 is optional. 

We could just leave it at that, and leave it to the FCC to = mandate VP8 if they want.
Adam suggested = that given the realities, H.264 as MTI is acceptable.  That=E2=80=99s= okay with me.

Or, we could = mandate VP8 support by providers on the RUE interface without requiring = that RUEs support it. That would allow new RUE implementations that = support VP8, but would still allow RUE implementations without it so = that old devices can be supported. (In particular, the potential = upgrading of existing provider supplied equipment.)
=E2=80=9CBy the providers=E2=80=9D could = be interpreted in several ways.  One is that the interface supports = VP8.  I certainly hope that=E2=80=99s a requirement.  Another = is that an endpoint that the provider has, specifically, the CA=E2=80=99s = workstation, or the videomail endpoint, supports VP8.  I wouldn=E2=80= =99t have any text in our document that would require that.  As a = practical matter, what that means is that if two RUE devices on = different providers negotiated VP8, that it would work, but if we looked = at the offer from, say, the CA, we may or may not see VP8.  Does = that make sense?  Is that okay?


This requires further discussion of what we are trying to = accomplish.

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.
Yeah, although I have a pretty hard time not = mandating MWI.  I really don=E2=80=99t think there is a reasonable = way to build a client without supporting MWI, since there is no other = interface to support the function.

IIUC (I might not) at least some = providers now provide a non-SIP mechanism for retrieving video mail. (A = web interface?)
A web interface is = fine, and I=E2=80=99m not arguing for mandating any particular way to = retrieve VM, but I think it=E2=80=99s pretty important that the UI of a = RUE be able to show that there is VM waiting, and I think MWI is the = only standards based way to provide an interface that would let it do = that.


However, that = might not be accessible to users with a conforming RUE. Potentially they = could simply say they don't support receiving video mail via SIP. In the = past we had some language that said if the RUE spec makes a feature = optional, they a provider MUST provide it if they have a comparable = proprietary feature.
Yeah, I don=E2=80=99= t want to see that kind of language in an IETF doc.  The regulator = could say that, not us.

We can check, but I suspect that *every* provider has video = mail. If so, they making this MTI makes sense to me.

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?

Hmmm. Is that a UI issue, and = thus beyond scope, or an interface issue and in scope?

We can specify the need to provide the feature without = specifying what it looks like in the UI. This is analogous the requiring = the support of MWI.

It seems likely to me that the providers will provide a RUE = implementation that runs on some of their already deployed hardware. = They most likely won't want to enable it to choose another provider. We = need to decide if that is ok or not. Or we can leave it to the FCC to = decide.
I think the interface (in this = case, I think this is a json object in a file) has to support it. =  I don=E2=80=99t know if we need to go any farther.


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.\\
Yeah, I=E2=80=99m = pretty heavily dealing with this in other venues.  I think we want = json schemas.  I=E2=80=99ll do that next rev.

Sounds like you are more up to speed than I am.
Yeah, probably

= Thanks,
= Paul

= --Apple-Mail=_3DA32267-0444-46D7-82FB-D64D69052592-- From nobody Tue Feb 25 09:01: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 677923A1098 for ; Tue, 25 Feb 2020 09:01:24 -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, 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 OWdYeWgDWunK for ; Tue, 25 Feb 2020 09:01:22 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2048.outbound.protection.outlook.com [40.107.220.48]) (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 2ECA23A1090 for ; Tue, 25 Feb 2020 09:01:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hzau9eZS7jSpLcPO94YOiXVmabsBx51PpCHcZxzetASeQOByQq8nB1cZHRCjALM+8M+dQnW3FdztIop5kmt5LhO7bupJz+TOkp/VuiKPR93JkKdND+eFrPGpk0Op56uD0LYjCsptMI8qfFWgJjxG1mNenbm7a5aE9azi1q4DOFlIGwDxiTXq5rE4XZoKOYukDrgXDSL1mTmGBtWpCmK/02VWs/fnIHVOZJqKIoXrzXDmmANl4tCssjkbFEBhj2KlkrUctqPzq5/9moRI6iiDXoaUKuTS61SLbE4SPogZGnlA4Ht0Oh5KZZ4+aeds0/dzlnA+axoWWaQa7o5g3uuO9w== 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=jonPuUbMsK3TU9pIx8SXF+QutgIrBDPbYL/PAdshKB8=; b=SfJXVO18ncS5KDnOaLAe8GxABotU101163a/XBju5/WsvsNpqD4Msyeik6txQyRDLaw0cMr4race6pEasmT2ystoaT2JM5kQNPxdlrd5BeZ725PPewNFTVUmvtKgQ5LK/dTgvIlW6KUm+cB89XX0mhdHdWIFjG1HhNo24xhnwPM8RBxf6zCGEx7aPjpPB6Kchqqpi0Z2FtYBaVg61HtPDOetGYqTVzty4VP+dm+SdGlRjOkXLbkh0vxQv0koBfOYm/WETPKV8i6gsGCDpltBi2uPUJyokjvvsNZoMpJki5eHmw1HLLYyI1IReX0biwDRtiL6zI0/g7l/KWaK1fI5iw== 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=jonPuUbMsK3TU9pIx8SXF+QutgIrBDPbYL/PAdshKB8=; b=ewtzFEJIFPjn8vak5Rs3JQm0Uu4ylQ+jhwCapNJBSld6xyNrVud9DIQrqB1jB2U5lBsjaB8ioahCjpp1uLaUWxc+fhpwh8SHDYKDxEg3/i6NzCQ7scBKPS+dZu8dwRkZ+OtsLsHd+79kMAcL5Evl5qNMAuMR6I5uQvSv1sceLNk= Received: from SN4PR0401CA0013.namprd04.prod.outlook.com (2603:10b6:803:21::23) by MWHPR1201MB0015.namprd12.prod.outlook.com (2603:10b6:300:df::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Tue, 25 Feb 2020 17:01:17 +0000 Received: from SN1NAM02FT026.eop-nam02.prod.protection.outlook.com (2603:10b6:803:21:cafe::8) by SN4PR0401CA0013.outlook.office365.com (2603:10b6:803:21::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Tue, 25 Feb 2020 17:01:17 +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 SN1NAM02FT026.mail.protection.outlook.com (10.152.72.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.19 via Frontend Transport; Tue, 25 Feb 2020 17:01: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 01PH1DG3004608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Feb 2020 12:01:14 -0500 To: rum@ietf.org References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net> From: Paul Kyzivat Message-ID: <629ab9cb-7487-f05e-e06a-57dc9ae551e7@alum.mit.edu> Date: Tue, 25 Feb 2020 12:01:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.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-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(136003)(199004)(189003)(53546011)(6916009)(70586007)(2906002)(186003)(31686004)(26005)(70206006)(336012)(2616005)(956004)(7596002)(86362001)(31696002)(8936002)(786003)(356004)(478600001)(246002)(36906005)(316002)(66574012)(26826003)(75432002)(5660300002)(8676002)(30864003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1201MB0015; 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: 718fbda7-6f9c-4933-01dc-08d7ba1453a3 X-MS-TrafficTypeDiagnostic: MWHPR1201MB0015: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0324C2C0E2 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mDPzfynouO6ylbTKxLXwIlzcgtgUgFDTcUYDrVwi8lxRQPYCqIHwS5Fv3+VNHhKcAWAD3eWCb0Hqe1NLVrhiYos59PjnvOgwHDGxWXzkeGZ8px8W0dSF1tIFoDPRoRVzRXZONm9gjRABbQfv+Uedody2ifLEP6zgrrJxVfg0LrnjxO5FSHSZ820RS9JIk0Ii7BWE1BiEA+uWgdM+0eECAkTqKwkqeAxFiQvVL+A2hupznjRo6Ir9QajapmNR/FSouYtfWfy9vSRTcReiRrmSeRVYGYVJoLO4mnQ6na+1fvlXRw2tfPVotGAUUAowWgyEj/ixISi0+5iiojun+4svqR0P5ngChQDzNFFrItfd/W24+34Ct9XTRJr0yCjow/nVMaAOADw3P/RZRwz9SNkzvkGWWUjrIThUYkCMrFRmkPTtqXccDT6UepkbONuNWSTV X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2020 17:01:15.7995 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 718fbda7-6f9c-4933-01dc-08d7ba1453a3 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: MWHPR1201MB0015 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: Tue, 25 Feb 2020 17:01:25 -0000 Brian, responses inline... On 2/24/20 12:53 PM, Brian Rosen wrote: > Inline > >> On Feb 19, 2020, at 2:24 PM, Paul Kyzivat > > wrote: [snip] >> My point in general though is that most of these protocols specify >> differing behavior on the two ends of a connection. Sometimes this is >> UAC vs. UAS, but not always. So at least I think we need to profile >> what part each end must support. >> >> For instance: >> >> - when outbound is in use, the roles of the RUE and the provider are >> clearly distinct. E.g. the RUE is responsible for setting of the >> connections to the server, and keeping them up as long as it wants the >> possibility of receiving a call. >> >> - for MWI the RUE is always the subscriber and the provider is always >> the publisher. >> >> - for location information I should probably have called out RFC6881 >> rather than RC6442. The RUE will be the one including geoloc info, and >> the provider acting on it. I don't think there is any requirement or >> expectation that geoloc info flows from the provider to the RUE. > But ISTM that all we need do it say that conformance to the appropriate > standards is required.  Those standards specify what each end has to do. >  Our document doesn’t need to specify. I'll have to review 6881 so see if it will be clear which end is which in our context. >>> There are some differences, but I’d prefer to use “UAC and “UAS” as >>> the terms. >> >> Rarely is that the proper distinction for this. E.g., for MWI the RUE >> is the UAC for subscriptions, but is UAS for the notifications. > I think that is one of the few exceptions.  We can use “client” and > “server” when we need to. Currently UAC and UAS aren't used. So I guess I'll have to wait to see what works. >>>> 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.) >>> Yes, but doesn’t the text read correctly? >> >> IMO the old way was right. ("The RUE MUST route all calls through the >> outbound proxy ...") >> >> This of course depends on what you mean by an outbound call. A call >> *to* a particular RUE in inbound from the RUE perspective, but what is >> it from the perspective of the interpreter at the provider that is >> initiating it? > I don’t think in this document we are concerned about what the > interpreter is sitting in front of.  I’d like it to be a RUE, but it > doesn’t have to be (unless the regulator says it has to be).  All that > we are concerned with here is the interface between the RUE and the rest > of the ecosystem, which will have providers, other RUE devices and some > non-RUE devices we want to be backwards compatible with. The tricky part is that rtcweb is defining behavior when establishing media between two conforming endpoints. In RUM, we will sometimes have calls where only one of the endpoint is conforming. The provider may then act as a bridge to the non-conforming device. While we don't need to say how that is done, we ought to take into account what the challenges will be and that we are confident that this can be done in a practical sense. But this is wandering from my issue with this section. My concern was whether the wording ("The all outbound calls MUST be routed") is clear regarding which calls it applies to. The old wording ("The RUE MUST route all calls") was crystal clear. The new wording is clear when read in the context of RFC5626. If the reader isn't thinking in that context, and especially if the reader is thinking about it from the point of view of a provider planning the implementation of his servers, they this might not be so clear. It isn't a big issue, but it just seems to me the change was unnecessary and didn't improve anything. [snip] >>>> 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. >>> I’ll change to UAC/UAS >> >> I don't think that works. UAC pertains only to a particular message. >> Both RUE and provider take both roles at various times. IIUC >> Additional Data is only ever sent in requests, not responses, so of >> course it will be a UAC that is sending. What is really important here >> is that it is the RUE that is sending the Additional Data. > Actually, the provider is most often the entity that sends Additional > Data.  The RUE might also, but the provider always does so. Then I guess I'm confused. Can you explain more? What is the use case for this. My quick rescan of 5626 confirms my impression that this is data flowing from the originator of the emergency call subsequent to the establishment of the call. For instance, a change in location. Also, it appears that additional data can be transmitted in both sip requests and responses, so by both UAC and UAS. If the RUE can receive additional data, then isn't there some need to specify what it is expected to do with it? [snip] >> Or, we could mandate VP8 support by providers on the RUE interface >> without requiring that RUEs support it. That would allow new RUE >> implementations that support VP8, but would still allow RUE >> implementations without it so that old devices can be supported. (In >> particular, the potential upgrading of existing provider supplied >> equipment.) > “By the providers” could be interpreted in several ways.  One is that > the interface supports VP8.  I certainly hope that’s a requirement. >  Another is that an endpoint that the provider has, specifically, the > CA’s workstation, or the videomail endpoint, supports VP8.  I wouldn’t > have any text in our document that would require that.  As a practical > matter, what that means is that if two RUE devices on different > providers negotiated VP8, that it would work, but if we looked at the > offer from, say, the CA, we may or may not see VP8.  Does that make > sense?  Is that okay? I think it is ok. I'm not certain if the providers would be happy even with that. IIUC, Sorenson is capable of negotiating e2e media between two RUEs, using ICE, and so would probably be able to do this. I think some of the others still always proxy the media. I don't know if they are able to proxy media using codecs they don't support. The provider profile only specifies the connections between providers. It doesn't specify at all how the signaling between RUE and provider relates to what the provider passes along to either another provider or to another RUE connected to the same provider. I think RUM will of necessity cause us to define some of that. We need to think about that part. This is probably only so for p2p calls between RUM-compliant RUEs. How much we need to specify for relay calls or video mail answered calls is a whole different question. >> This requires further discussion of what we are trying to accomplish. >> >>>> 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. >>> Yeah, although I have a pretty hard time not mandating MWI.  I really >>> don’t think there is a reasonable way to build a client without >>> supporting MWI, since there is no other interface to support the >>> function. >> >> IIUC (I might not) at least some providers now provide a non-SIP >> mechanism for retrieving video mail. (A web interface?) > A web interface is fine, and I’m not arguing for mandating any > particular way to retrieve VM, but I think it’s pretty important that > the UI of a RUE be able to show that there is VM waiting, and I think > MWI is the only standards based way to provide an interface that would > let it do that. ISTM that if the provider stores messages for retrieval by the VRS user then there must be some way for the standard RUE to retrieve them. If this is a web interface, then do we need to specify that all RUEs have a browser UI? Alternately, retrieval can be by calling a special number. ISTM that at the very least, we would want to ensure that that RUE has some standard way to learn that there are messages waiting, to notify the user of that, and to provide the user with a way to retrieve those messages. It seems important that this continues to work when the RUE gets service from a different provider. [snip] >> We can check, but I suspect that *every* provider has video mail. If >> so, they making this MTI makes sense to me. >> >>>> 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? >>>> >>> Hmmm. Is that a UI issue, and thus beyond scope, or an interface >>> issue and in scope? >> >> We can specify the need to provide the feature without specifying what >> it looks like in the UI. This is analogous the requiring the support >> of MWI. >> >> It seems likely to me that the providers will provide a RUE >> implementation that runs on some of their already deployed hardware. >> They most likely won't want to enable it to choose another provider. >> We need to decide if that is ok or not. Or we can leave it to the FCC >> to decide. > I think the interface (in this case, I think this is a json object in a > file) has to support it.  I don’t know if we need to go any farther. Just to be clear: The RUE will need to *know* what providers to attempt to register with. The interface that returns the list of providers, coupled with some UI the presents that to the user, is one way of accomplishing that. Another way is a UI that allows the user to manually configure the provider. And preconfiguring the RUE before delivering it to the user, with no user override, is yet another way. We need to decide if there are any of these that we want to mandate be available. Or we might want to define some *optional* specs for one or more of these that are then available for a regulatory agency to call out if they wish. [snip] Thanks, Paul From nobody Fri Feb 28 14:37:44 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 709F63A1F42; Fri, 28 Feb 2020 14:35:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: adam@nostrum.com, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931443.19931.1354682411397257559@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:14 -0800 Archived-At: Subject: [Rum] rum - Requested session has been scheduled for IETF 107 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: Fri, 28 Feb 2020 22:35:20 -0000 Dear Paul Kyzivat, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rum Session 1 (1:00 requested) Monday, 23 March 2020, Afternoon Session III 1810-1910 Room Name: Georgia A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/rum.ics Request Information: --------------------------------------------------------- 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: 15 Conflicts to Avoid: Technology Overlap: avtcore dispatch modern sipcore ecrit mmusic quic People who must be present: Adam Roach Brian Rosen Paul Kyzivat Resources Requested: Special Requests: ---------------------------------------------------------