Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration

Brian

We do need to be clear, that:-

  *   A VRS user needs an account with a provider before they can use the service.
  *   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

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 <pkyzivat@alum.mit.edu> 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
>
>