Subject: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

From: [email-masked]
Date: Fri, 05 Feb 2021 14:17:15 -0800

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-04.txt
	Pages           : 33
	Date            : 2021-02-05

Abstract:
   Video Relay Service (VRS) is a term used to describe a method by
   which a hearing persons can communicate with deaf/Hard of Hearing
   user using an interpreter ("Communications Assistant") connected via
   a videophone to the deaf/HoH user and an audio telephone call to the
   hearing user.  The CA interprets using sign language on the
   videophone link and voice on the telephone link.  Often the
   interpreters may be supplied by a company or agency termed a
   "provider" in this document.  The provider also provides a video
   service that allows users to connect video devices to their service,
   and subsequently to CAs and other deaf/HoH users.  It is desirable
   that the videophones used by the deaf/HoH/H-I user conform to a
   standard so that any device may be used with any provider and that
   video calls direct between deaf/HoH users work.  This document
   describes the interface between a videophone and a provider.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-rum-rue-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04

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

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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 5 Feb 2021 17:26:33 -0500

I have posted a -04 revision.  This should handle all comments received so far, please let me know if I forgot something.

This version reworks the provider list and configuration sections along the lines we have been discussing.

I do not have a way to download a username/password from a new signup.  I’m having trouble thinking about a secure way to do that.  If anyone has an idea, I’m very willing to write text for it.  I’ve considered things like javascript that stashes it in a file or somewhere else, having some web page function that triggers a local display of an entry form for username and password, and a couple of other things.

One note on the configuration mechanism - because the only thing the local RUE device needs to keep is the username password against a provider ID of some kind, there isn’t any need to standardize how that works, and so it’s completely absent in the text.  

For now, I’ve removed the step by step diagram that showed how the config mechanism is used.  I think what is there is dead simple and needs no explanation: it’s a straightforward REST/JSON web service using username/password authentication for providers the user has accounts with.  I can bring back the diagram if that is needed.

Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-ietf-rum-rue-04.txt
> Date: February 5, 2021 at 5:17:15 PM EST
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked], [email-masked]
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 6 Feb 2021 14:04:38 -0500

On 2/5/21 5:26 PM, Brian Rosen wrote:
> I have posted a -04 revision.  This should handle all comments received 
> so far, please let me know if I forgot something.
> 
> I do not have a way to download a username/password from a new signup. 
>   I’m having trouble thinking about a secure way to do that.  If anyone 
> has an idea, I’m very willing to write text for it.  I’ve considered 
> things like javascript that stashes it in a file or somewhere else, 
> having some web page function that triggers a local display of an entry 
> form for username and password, and a couple of other things.

IMO it is ok for the RUE, when attempting to connect to the provider for 
the first time, to do a normal authentication prompt to the user. (I 
think it is reasonable to expect the user to be present at the first 
attempt to connect.

This does have an implication on the interface. Right now an attempt to 
connect without a userid acts differently from one with a userid. It 
would be necessary to change this so that these are distinguished in 
some other way. Then a "normal" attempt to connect without a userid 
would result in an authentication challenge that the user can respond to.

One reason I think this is ok is because we can't really assume that the 
user does the signup using a browser controlled by the RUE. The user 
might do this separately from a computer or phone, and perhaps even 
before obtaining the RUE.

(In above, "attempt to connect" applies to sip register, mwi 
subscription, and request for configuration.)

	Thanks,
	Paul

> One note on the configuration mechanism - because the only thing the 
> local RUE device needs to keep is the username password against a 
> provider ID of some kind, there isn’t any need to standardize how that 
> works, and so it’s completely absent in the text.
> 
> For now, I’ve removed the step by step diagram that showed how the 
> config mechanism is used.  I think what is there is dead simple and 
> needs no explanation: it’s a straightforward REST/JSON web service using 
> username/password authentication for providers the user has accounts 
> with.  I can bring back the diagram if that is needed.
> 
> Brian
> 
> 
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D Action: draft-ietf-rum-rue-04.txt*
>> *Date: *February 5, 2021 at 5:17:15 PM EST
>> *To: *<[email-masked] <mailto:[email-masked]>>
>> *Cc: [email-masked] <mailto:[email-masked]>
>> *Reply-To: [email-masked] 
>> <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>>
>>
>> <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 6 Feb 2021 17:08:26 -0500

Brian,

Comments on this posted version:

* "Dial-around call": what about inbound dial-around calls? Is there 
anything meaningful that we can say about them? IIUC the only way to 
achieve that is for the hearing user to dial the front door number of 
the provider he wants to handle the call. If that is the only way then 
the RUE and its user are not involved and so nothing can/should be said.

* "RUE Interface": s/the VRS provider/a VRS provider/

*  5.2.4 Incoming Calls:

This says:

    The RUE MUST only accept inbound calls sent to it by the proxy
    mentioned in the configuration.

First, there can be multiple configured proxies, so s/the proxy/a proxy/.

But IIUC if proxies are configured then the RUE is require to use 
[RFC5626] (Outbound). But the provider isn't required to support/use 
outbound. What is to happen with a provider that doesn't? Perhaps we 
need to separate the configuration of proxies from configuring the use 
of outbound with those proxies.

If outbound *is* used then it is easy to determine that incoming calls 
arrive from the proxy. But if outbound *isn't* used then there isn't any 
obvious way for the RUE to figure this out.

ISTM we either must *require* use of outbound, or remove this 
requirement to only accept calls from the configured proxy, or detail 
how to do this verification in the absence of outbound.

(I think there may be some resistance to use of outbound in mobile RUEs 
because it can significantly increase the power demand.)

* 9.1 RUE Provider Selection

This section talks about backward compatibility without defining it. 
While people may have an intuitive understanding of it, they may not all 
understand it the same way.

It may be better to define this as a requirement that if you advertise 
support for M.N you are also implicitly promising that you support M.i 
for 0<=i<N. (There will be implications on how the spec for a new minor 
version is defined in order to make it feasible for implementations to 
make this guarantee, but we need not go into that.)

The phrase "The provider list is a json object" should perhaps say: "The 
v1.0 provider list is a json object".

This way of handling versioning has one limitation: The manner of 
retrieving the version list must remain supported for all future 
versions. Alternatively, we might instead put some or all of this 
version info into the IANA registry, so that future versions might 
require some other sort of interface.

* 9.2 RUE Configuration Service:

What is the intended purpose/use of the language tags? Should this 
indicate the spoken language supported by the interpreter for 
interacting with hearing people? Or the written language on a web 
interface? Or the language used in finger spelling? Or different 
versions of sign language?

For dialAround and helpDesk, should there be a URI or phone number or 
both? How would the RUE and deaf user use the URI to initiate a call? 
(Currently the spec constrains the To URI in a call to be based on an 
E164 number.) We don't specify the UI, but presumably the RUE might 
offer special UI for these, or not. If not then I guess it would have to 
make this configuration info available somehow. Else these things could 
be pre-populated in the address book. (I think that is how providers do 
it today.)

Re "outbound-proxy": this needs to be a list/array to allow multiple 
values. The example shows this (and calls the key "outbound-proxies") 
but the description is singular and doesn't mention an array.

The following:

    The configuration API also provides the same version mechanism as
    specified above in Section 9.1.  The version of the configuration
    service MAY be different than the version of the configuration
    service.

has a problem. s/configuration service./provider list service./

Finally, a style issue: The keywords are named in a mixture of camelCase 
and hyphenated words. (Like snake-case but with hyphens instead of 
underscores. I don't know of a name for this.) I think we need to pick a 
consistent style.

* 9.4 OpenAPI Interface Descriptions

I don't know yaml, so I'm not going to attempt to comment on this now. 
I'll aim to come back after studying up on it.

More inline below.

> with.  I can bring back the diagram if that is needed.

I still think that we need to discuss the flows that can occur *after* 
enrollment and initial use.

Of particular note: passwords eventually must be changed, for a variety 
of reasons. E.g., user preference, provider age-out of a password, 
compromise of provider credential storage.

In each case the RUE will need to discover this and update its 
credential store. The user will need to enter the password into the RUE, 
which means the user must be present at the RUE and either respond to a 
prompt to make the change or actively request to change it.

If the need for a new password occurs when the user is not present at 
the RUE, then it probably means that the user will no longer have 
incoming phone service until he notices. That is potentially a safety 
problem. So we should consider how to minimize this case.

For instance, a few days/weeks before the provider ages out the 
password, it should notify the user, so the user can actively change the 
password and update the RUE. Of course the provider can do this 
out-of-band via email, but it would be nice to have a way to cause the 
RUE to inform the user. E.g., perhaps a MESSAGE sent from the provider 
to the RUE, that the RUE can then display.

(And when the provider does invalidate a password the RUE should have 
enough information so it can take action to alert the user that action 
is required on his part to restore service. But 401 or 404 responses are 
probably sufficient to trigger this.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Feb 2021 19:48:09 -0500

Replying to myself with further thoughts...

> to the RUE, that the RUE can then display.

I realized that we already have a mechanism that providers could use to 
deliver this sort of notification: video mail.

Given that, I will drop this concern.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 8 Feb 2021 19:48:51 -0500

Thanks for the comments.  Responses inline

> On Feb 6, 2021, at 5:08 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Brian,
> 
> * "Dial-around call": what about inbound dial-around calls? Is there anything meaningful that we can say about them? IIUC the only way to achieve that is for the hearing user to dial the front door number of the provider he wants to handle the call. If that is the only way then the RUE and its user are not involved and so nothing can/should be said.
Yeah, the RUE doesn’t directly deal with them.  They go to the default provider, who forwards them to the RUE.  Do we need to say that?

> * "RUE Interface": s/the VRS provider/a VRS provider/
Fixed
> First, there can be multiple configured proxies, so s/the proxy/a proxy/.
Fixed
> 
> But IIUC if proxies are configured then the RUE is require to use [RFC5626] (Outbound). But the provider isn't required to support/use outbound. What is to happen with a provider that doesn't? Perhaps we need to separate the configuration of proxies from configuring the use of outbound with those proxies.
Can we say that if multiple proxies are mentioned the provider MUST support Outbound?

> 
> If outbound *is* used then it is easy to determine that incoming calls arrive from the proxy. But if outbound *isn't* used then there isn't any obvious way for the RUE to figure this out
> 
> ISTM we either must *require* use of outbound, or remove this requirement to only accept calls from the configured proxy, or detail how to do this verification in the absence of outbound.
> 
> (I think there may be some resistance to use of outbound in mobile RUEs because it can significantly increase the power demand.)
> 
> This section talks about backward compatibility without defining it. While people may have an intuitive understanding of it, they may not all understand it the same way.
> 
> It may be better to define this as a requirement that if you advertise support for M.N you are also implicitly promising that you support M.i for 0<=i<N. (There will be implications on how the spec for a new minor version is defined in order to make it feasible for implementations to make this guarantee, but we need not go into that.)
I reworded it to say:
To achieve backwards compatibility, implementations MUST ignore any object members they do not implement and minor version definitions SHALL only add objects, non-required members of existing objects, and non-mandatory-to use functions and SHALL NOT delete any objects, members of objects or functions.  This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version. 

> 
> The phrase "The provider list is a json object" should perhaps say: "The v1.0 provider list is a json object”.
Fixed

> 
> This way of handling versioning has one limitation: The manner of retrieving the version list must remain supported for all future versions. Alternatively, we might instead put some or all of this version info into the IANA registry, so that future versions might require some other sort of interface.
Yes, the version mechanism has to remain available and at least backwards compatible to V1.  I don’t think that is a problem, and there are no protocol police if some future work group breaks the assumption.

> What is the intended purpose/use of the language tags? Should this indicate the spoken language supported by the interpreter for interacting with hearing people? Or the written language on a web interface? Or the language used in finger spelling? Or different versions of sign language?
Sign language for interacting with the RUE user

> 
> For dialAround and helpDesk, should there be a URI or phone number or both? How would the RUE and deaf user use the URI to initiate a call? (Currently the spec constrains the To URI in a call to be based on an E164 number.) We don't specify the UI, but presumably the RUE might offer special UI for these, or not. If not then I guess it would have to make this configuration info available somehow. Else these things could be pre-populated in the address book. (I think that is how providers do it today.)
For the help desk, I wanted this to not require an existing relationship with any provider.  So it’s a SIP URI that doesn’t need a proxy that establishes a video call to a sign-language capable helper.

For dial around, it’s whatever it takes to video call point-to-point using the default provider.  In the US that would be a 10 digit number that was in the iTRS Directory, but that might be different in some other country

Suggestions on wording?

> 
> Re "outbound-proxy": this needs to be a list/array to allow multiple values. The example shows this (and calls the key "outbound-proxies") but the description is singular and doesn't mention an array.
I can fix that, but I want to ask if there is an actual use case for it?  Why would a provider have more than one URI for a particular user/phone number?  Happy to fix it, but we would need to say how the RUE uses it.  Incoming is clear (accept calls from any configured proxy).
> has a problem. s/configuration service./provider list service./
Fixed
> 
> Finally, a style issue: The keywords are named in a mixture of camelCase and hyphenated words. (Like snake-case but with hyphens instead of underscores. I don't know of a name for this.) I think we need to pick a consistent style.
Pick one and I’ll fix everything to be consistent.  I like camelCase, but don’t care
> I don't know yaml, so I'm not going to attempt to comment on this now. I'll aim to come back after studying up on it.
> 
> More inline below.
> 
> I still think that we need to discuss the flows that can occur *after* enrollment and initial use.
> 
> Of particular note: passwords eventually must be changed, for a variety of reasons. E.g., user preference, provider age-out of a password, compromise of provider credential storage.
> 
> In each case the RUE will need to discover this and update its credential store. The user will need to enter the password into the RUE, which means the user must be present at the RUE and either respond to a prompt to make the change or actively request to change it.
> 
> If the need for a new password occurs when the user is not present at the RUE, then it probably means that the user will no longer have incoming phone service until he notices. That is potentially a safety problem. So we should consider how to minimize this case.
> 
> For instance, a few days/weeks before the provider ages out the password, it should notify the user, so the user can actively change the password and update the RUE. Of course the provider can do this out-of-band via email, but it would be nice to have a way to cause the RUE to inform the user. E.g., perhaps a MESSAGE sent from the provider to the RUE, that the RUE can then display.
> 
> (And when the provider does invalidate a password the RUE should have enough information so it can take action to alert the user that action is required on his part to restore service. But 401 or 404 responses are probably sufficient to trigger this.)
Since, at the moment, there is no mechanism other than manual entry for the RUE to learn the username and password, I think all of this is also manual.  We could add mechanism for a password update if that’s helpful without the initial password capture, but that would only be secure if it used the old password to authenticate to update to a new one.   

> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>> Begin forwarded message:
>>> 
>>> *From: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> *To: *<[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> *Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> *Reply-To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/> <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>>
>>> 
> -- 
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: James Hamlin <[email-masked]>
Date: Tue, 9 Feb 2021 09:42:33 +0000

Brian

Section 5.1 Registration says that "The credentials to be used (username and password) MUST be supplied within the credentials section of the configuration and identified by the realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as that used for other purposes, such as retrieving the RUE configuration or logging into the Provider's customer service portal.". However, in the 04 draft, passwords are no longer returned in the configuration. I think we need to avoid the RUM RUE caching the user's main account password, which this draft seems to require.

Best regards

James

James Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com
The information contained in this e-mail message is intended
only for the personal and confidential use of the recipient(s)
named above. If you have received this communication in error,

please notify us immediately by e-mail, and delete the original
message.

________________________________
From: Rum <[email-masked]> on behalf of Brian Rosen <[email-masked]>
Sent: 05 February 2021 22:26
To: [email-masked]
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

Brian

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM EST
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Reply-To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-ietf-rum-rue%2f&c=E,1,mUfzZSvT0R5PlIULOAhGXxKnxVeCQEEHHa9CcPT3-HqNaT9hM5JK3bj6GsyE5Z7rS4E0Ag6K-nz1zOaSSEx_Z5al6a93HJMLoWRLlBL4KSlp0XX655sBg1s,&typo=1>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-rum-rue-04.html<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2farchive%2fid%2fdraft-ietf-rum-rue-04.html&c=E,1,MjPZzNPUM7X1lihxnBodY5Wmd7JZ1ClxD3i4H0Vi6po3k4JEQRMj9m_9itObrtC0UKgMkicqPmiKoLjRFMvn97wGLpnpjBAuJ-cI83QseuV6Hmdrf9FgDaxqLJS8&typo=1&ancr_add=1>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-ietf-rum-rue-04&c=E,1,8tQnEtlegYiKOkEOt7SIhL8J6UsMU0qi7LLjUXG39irjmFX6TMnHZeUaiRF67Ax3NCmrbI0DaTbxdmVoEgmjwbfLhQJCROy9s9YEsPurwAtCIV-R7GQ_otwSEQ,,&typo=1&ancr_add=1>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2finternet-drafts%2f&c=E,1,qDB4Sa2C6-PUy-DdKkOONbaugXYz_8IeqrS01IJYp5AJZMDsv0j8-7OF8wVyrR1c4ge_Vw5Jtle86A2D3EBaQmxvtVwuNm-n4qhgkMvEl1QRG4Gr&typo=1&ancr_add=1>

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fi-d-announce&c=E,1,gMXWIIto0AlXSlk-Z8WD3kueYFOpPzfA7iwWXrPkW8IiV3-Vro35CfBR_RFgEDnzITOLWlUs8QZczHEvNieXllnk23SMFSscN7cjcKbXisPp3IABh7ejzeDH&typo=1&ancr_add=1>
Internet-Draft directories: http://www.ietf.org/shadow.html<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.ietf.org%2fshadow.html&c=E,1,HR_C8Vd1qpafcIvWmHsVkCYmawB4ZVJwfpeRKNADifBFpRFAse2RORKxL4mn_LAWeYT4KuzfSKmorx8kodAoz2xW6oh7KayjcwLY8Odb5Q,,&typo=1&ancr_add=1>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2fietf%2f1shadow-sites.txt&c=E,1,uNHUH3kpH5hvg6n7w0YvSCPq6n1fGvOQJLOPGzDQOEdUxaa_nxcLahrU8m8bpFUXPqoLYjHqDyOBGRjpGMQzlIvtBZYrshNEEfc8K86xQA,,&typo=1&ancr_add=1>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Feb 2021 08:43:41 -0500

I’ll delete the text in registration.  
Every VoIP phone I’ve ever seen or used caches username and passwords for stand alone use.  Every one.  They do that for a simple reason - so incoming calls work after a power loss.  Most also are effectively set and forget, which is what you want in a phone.  Why would we require manual entry for the RUE?

The text currently uses the same credentials for the HTTP service and the SIP service, but that’s it.  I think that’s pretty reasonable.

If you have another proposal for how we can maintain the config data securely, please suggest one.

Brian

> On Feb 9, 2021, at 4:42 AM, James Hamlin <[email-masked]> wrote:
> 
> Brian
> 
> purplevrs.com <http://purplevrs.com/>
>> From: [email-masked] <mailto:[email-masked]>
>> To: <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>> Reply-To: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-ietf-rum-rue%2f&c=E,1,mUfzZSvT0R5PlIULOAhGXxKnxVeCQEEHHa9CcPT3-HqNaT9hM5JK3bj6GsyE5Z7rS4E0Ag6K-nz1zOaSSEx_Z5al6a93HJMLoWRLlBL4KSlp0XX655sBg1s,&typo=1>
>> 
>> https://www.ietf.org/archive/id/draft-ietf-rum-rue-04.html <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2farchive%2fid%2fdraft-ietf-rum-rue-04.html&c=E,1,MjPZzNPUM7X1lihxnBodY5Wmd7JZ1ClxD3i4H0Vi6po3k4JEQRMj9m_9itObrtC0UKgMkicqPmiKoLjRFMvn97wGLpnpjBAuJ-cI83QseuV6Hmdrf9FgDaxqLJS8&typo=1&ancr_add=1>
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04 <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-ietf-rum-rue-04&c=E,1,8tQnEtlegYiKOkEOt7SIhL8J6UsMU0qi7LLjUXG39irjmFX6TMnHZeUaiRF67Ax3NCmrbI0DaTbxdmVoEgmjwbfLhQJCROy9s9YEsPurwAtCIV-R7GQ_otwSEQ,,&typo=1&ancr_add=1>
>> 
>> 
>> ftp://ftp.ietf.org/internet-drafts/ <https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2finternet-drafts%2f&c=E,1,qDB4Sa2C6-PUy-DdKkOONbaugXYz_8IeqrS01IJYp5AJZMDsv0j8-7OF8wVyrR1c4ge_Vw5Jtle86A2D3EBaQmxvtVwuNm-n4qhgkMvEl1QRG4Gr&typo=1&ancr_add=1>
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fi-d-announce&c=E,1,gMXWIIto0AlXSlk-Z8WD3kueYFOpPzfA7iwWXrPkW8IiV3-Vro35CfBR_RFgEDnzITOLWlUs8QZczHEvNieXllnk23SMFSscN7cjcKbXisPp3IABh7ejzeDH&typo=1&ancr_add=1>
>> Internet-Draft directories: http://www.ietf.org/shadow.html <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.ietf.org%2fshadow.html&c=E,1,HR_C8Vd1qpafcIvWmHsVkCYmawB4ZVJwfpeRKNADifBFpRFAse2RORKxL4mn_LAWeYT4KuzfSKmorx8kodAoz2xW6oh7KayjcwLY8Odb5Q,,&typo=1&ancr_add=1>
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2fietf%2f1shadow-sites.txt&c=E,1,uNHUH3kpH5hvg6n7w0YvSCPq6n1fGvOQJLOPGzDQOEdUxaa_nxcLahrU8m8bpFUXPqoLYjHqDyOBGRjpGMQzlIvtBZYrshNEEfc8K86xQA,,&typo=1&ancr_add=1>
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Feb 2021 09:18:46 -0500

On 2/9/21 8:43 AM, Brian Rosen wrote:
> Every VoIP phone I’ve ever seen or used caches username and passwords 
> for stand alone use.  Every one.  They do that for a simple reason - so 
> incoming calls work after a power loss.  Most also are effectively set 
> and forget, which is what you want in a phone.  Why would we require 
> manual entry for the RUE?
> 
> The text currently uses the same credentials for the HTTP service and 
> the SIP service, but that’s it.  I think that’s pretty reasonable.
> 

I've been asking about this for awhile. As currently structured, it is 
up to the provider to agree with the user on which id/pw to be used by 
the RUE. That *could* be the same as the user uses to access the 
provider's web site for general administration, or it could be different.

I agree with Brian that it makes sense to me to use the same credentials 
for sip and the configuration service.

I have a little more doubt about the credentials for CardDAV. There are 
public implementations of this (e.g., Gooogle Contacts) that might be 
used, and could be configured. It probably wouldn't make sense to share 
credentials here. OTOH, maybe the *configured* CardDAV service would 
only apply for one managed by the provider. If the user wants to use a 
public CardDAV service perhaps he would independently configure that on 
the RUE, independent of provider configuration. We should perhaps talk 
further about this.

	Thanks,
	Paul

> Brian
> 
>> On Feb 9, 2021, at 4:42 AM, James Hamlin <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Brian
>>
>> Section 5.1 Registration says that "The credentials to be used 
>> (username and password) MUST be supplied within the credentials 
>> section of the configuration and identified by the realm the registrar 
>> uses in a digest challenge. This username/password combination SHOULD 
>> NOT be the same as that used for other purposes, such as retrieving 
>> the RUE configuration or logging into the Provider's customer service 
>> portal.". However, in the 04 draft, passwords are no longer returned 
>> in the configuration. I think we need to avoid the RUM RUE caching the 
>> user's main account password, which this draft seems to require.
>>
>> Best regards
>>
>> James
>>
>>
>>
>>
>> James Hamlin
>> Contractor
>> ------------------------------------------------------------------------
>> *From:*Rum <[email-masked] <mailto:[email-masked]>> on 
>> behalf of Brian Rosen <[email-masked] <mailto:[email-masked]>>
>> *Sent:*05 February 2021 22:26
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt
>> I have posted a -04 revision.  This should handle all comments 
>> received so far, please let me know if I forgot something.
>>
>> having some web page function that triggers a local display of an 
>> entry form for username and password, and a couple of other things.
>>
>> needs no explanation: it’s a straightforward REST/JSON web service 
>> using username/password authentication for providers the user has 
>> accounts with.  I can bring back the diagram if that is needed.
>>
>> Brian
>>
>>
>>> Begin forwarded message:
>>>
>>> *From:[email-masked] <mailto:[email-masked]>
>>> *Subject:**I-D Action: draft-ietf-rum-rue-04.txt*
>>> *Date:*February 5, 2021 at 5:17:15 PM EST
>>> *To:*<[email-masked] <mailto:[email-masked]>>
>>> *Cc:[email-masked] <mailto:[email-masked]>
>>> *Reply-To:[email-masked] 
>>> <mailto:[email-masked]>,[email-masked] <mailto:[email-masked]>
>>>
>>>
>>> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-ietf-rum-rue%2f&c=E,1,mUfzZSvT0R5PlIULOAhGXxKnxVeCQEEHHa9CcPT3-HqNaT9hM5JK3bj6GsyE5Z7rS4E0Ag6K-nz1zOaSSEx_Z5al6a93HJMLoWRLlBL4KSlp0XX655sBg1s,&typo=1>
>>>
>>> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2farchive%2fid%2fdraft-ietf-rum-rue-04.html&c=E,1,MjPZzNPUM7X1lihxnBodY5Wmd7JZ1ClxD3i4H0Vi6po3k4JEQRMj9m_9itObrtC0UKgMkicqPmiKoLjRFMvn97wGLpnpjBAuJ-cI83QseuV6Hmdrf9FgDaxqLJS8&typo=1&ancr_add=1>
>>>
>>> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-ietf-rum-rue-04&c=E,1,8tQnEtlegYiKOkEOt7SIhL8J6UsMU0qi7LLjUXG39irjmFX6TMnHZeUaiRF67Ax3NCmrbI0DaTbxdmVoEgmjwbfLhQJCROy9s9YEsPurwAtCIV-R7GQ_otwSEQ,,&typo=1&ancr_add=1>
>>>
>>>
>>> until the htmlized version and diff are available at tools.ietf.org 
>>> <http://tools.ietf.org>.
>>>
>>> <https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2finternet-drafts%2f&c=E,1,qDB4Sa2C6-PUy-DdKkOONbaugXYz_8IeqrS01IJYp5AJZMDsv0j8-7OF8wVyrR1c4ge_Vw5Jtle86A2D3EBaQmxvtVwuNm-n4qhgkMvEl1QRG4Gr&typo=1&ancr_add=1>
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fi-d-announce&c=E,1,gMXWIIto0AlXSlk-Z8WD3kueYFOpPzfA7iwWXrPkW8IiV3-Vro35CfBR_RFgEDnzITOLWlUs8QZczHEvNieXllnk23SMFSscN7cjcKbXisPp3IABh7ejzeDH&typo=1&ancr_add=1>
>>> Internet-Draft directories:http://www.ietf.org/shadow.html 
>>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.ietf.org%2fshadow.html&c=E,1,HR_C8Vd1qpafcIvWmHsVkCYmawB4ZVJwfpeRKNADifBFpRFAse2RORKxL4mn_LAWeYT4KuzfSKmorx8kodAoz2xW6oh7KayjcwLY8Odb5Q,,&typo=1&ancr_add=1>
>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>>> <https://linkprotect.cudasvc.com/url?a=ftp%3a%2f%2fftp.ietf.org%2fietf%2f1shadow-sites.txt&c=E,1,uNHUH3kpH5hvg6n7w0YvSCPq6n1fGvOQJLOPGzDQOEdUxaa_nxcLahrU8m8bpFUXPqoLYjHqDyOBGRjpGMQzlIvtBZYrshNEEfc8K86xQA,,&typo=1&ancr_add=1>
>>
>>
> 
>

---

From: Jim Malloy <[email-masked]>
Date: Tue, 9 Feb 2021 14:20:34 +0000

“Every VoIP phone I’ve ever seen or used caches username and passwords for stand alone use”

James –

Do existing ZVRS/Purple devices or mobile applications cache authentication credentials?  (Mobile applications may do so at the OS level even if the application doesn’t explicitly do so.)  If so, is there a reason to treat the RUE Differently?

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: Tuesday, February 9, 2021 8:44 AM
To: Hamlin, James <[email-masked]>
Cc: [email-masked]
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

Brian

On Feb 9, 2021, at 4:42 AM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Best regards

James

James Hamlin
Contractor
purplevrs.com<http://purplevrs.com/>

________________________________
From: Rum <[email-masked]<mailto:[email-masked]>> on behalf of Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 05 February 2021 22:26
To: [email-masked]<mailto:[email-masked]>
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

Brian

Begin forwarded message:

Abstract:

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<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

---

From: James Hamlin <[email-masked]>
Date: Tue, 9 Feb 2021 14:41:24 +0000

Jim

Yes credentials have to be cached, but not necessarily the user's primary account credentials. The previous text allowed the configuration service to send back separate credentials for SIP/STUN/TURN which could have a shorter validity period than the main account credentials. This offers greater flexibility in how a user's use of different RUE's can be isolated.

I'll accept that the provider could offer a separate password for use with each RUE type; we'd need to think about the logistical implications of that.

Best Regards

James

James Hamlin
Contractor

________________________________
From: Jim Malloy <[email-masked]>
Sent: 09 February 2021 14:20
To: Brian Rosen; James Hamlin
Cc: [email-masked]
Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

James –

Thanks,

Jim Malloy

Brian

Brian

Best regards

James

James Hamlin
Contractor
purplevrs.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,lHszv64tt0_3vwBuoJun-nx4WCNcqTTmH1eRB5etseOPqyLqiTiUBcbLjJjOw8-LNqVFBp6ocg3-Ex0Yf1VQWGob1gzB639RyM04xTf4VvBF48mh&typo=1>

Brian

Begin forwarded message:

Abstract:

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<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2ftools.ietf.org&c=E,1,4v8fNKuLbBZftOaLG3HnWCDj7G3Vbuozoee0zefXWUutbhixY92rsdDUAd3VVvv1kqgejs55PeHXY1nDWRpLsPcQL-JowBCzPJLzJiV4ImsnRv65oRxmnGYz4Dc,&typo=1>.

---

From: Eugene Christensen <[email-masked]>
Date: Tue, 9 Feb 2021 16:27:51 +0000

Hi Brian,

I have a few thoughts on this and a few typos that I’ll point out.

Substance Comments

  *   Section 4: Requirement for IPv4 and IPv6.  Why is IPv6 now a requirement?  Why not optional?
  *   Section 9.2 - The vetting process for a potential customer does not lend itself to a person being able to simply sign up like this.  The customer will be required to have an account before being able to communicate with the provider service.  I therefore believe we should remove the ability for the RUE device to communicate with the provider without a userid/password.
  *   Section 9.2 - In the section for the payload, it is missing the provider-domain in the text section but it is included in the example.  I expect this is simply an oversight.

Typo Comments

  *   Section 5.5,  Remove redundant "that" from first sentence "that that"
  *   Section 9,  2nd sentence reads awkwardly.  Perhaps change to "One provides a directory of providers so that a user interface allows easy provider selection ..."
  *   Section 9.1, get rid of extra "a" in the section "...a country code suitable for display, with a corresponding "a" URI ...
  *   Section 9.2, get rid of extra "the" in the first sentence "...provider configuration "the" using a simple..."
  *   Section 9.4 - Get rid of the redundant word "Sections" in the first sentence "The interfaces in "Sections" Section 9.1 ..."

Thanks.

Eugene Christensen.

CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked]<mailto:[email-masked]> or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.

From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: Friday, February 5, 2021 3:27 PM
To: [email-masked]
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

[EXTERNAL] I have posted a -04 revision.  This should handle all comments received so far, please let me know if I forgot something.

Brian

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Feb 2021 11:53:55 -0500

> On Feb 9, 2021, at 11:27 AM, Eugene Christensen <[email-masked]> wrote:
> 
> Hi Brian, 
>  
> Section 4: Requirement for IPv4 and IPv6.  Why is IPv6 now a requirement?  Why not optional?
Because the world has moved on, there are no more IPv4 addresses, many networks are IPv6 only now, and we need a good reason to not require it in the IETF.
> Section 9.2 - The vetting process for a potential customer does not lend itself to a person being able to simply sign up like this.  The customer will be required to have an account before being able to communicate with the provider service.  I therefore believe we should remove the ability for the RUE device to communicate with the provider without a userid/password.
The process has to start some how that doesn’t involve a phone call.  Take a really simple example: I’m deaf, I have an account with provider X, I want to establish another account with provider Y.  Can’t I do that with a website?  Can I get help via a videophone?  The way it’s currently defined all that happens is you get a URI for the website and another for a help desk.  You don’t get anything out of it.  When all the vetting is finished, you end up with a userid and password, and you manually enter that into the RUE.  What am I missing?

> Section 9.2 - In the section for the payload, it is missing the provider-domain in the text section but it is included in the example.  I expect this is simply an oversight.
It’s the domain in the provider-list.  I can make that clearer
> Typo Comments
Thanks for these, I’ll fix them
> Section 5.5,  Remove redundant "that" from first sentence "that that"
> Section 9,  2nd sentence reads awkwardly.  Perhaps change to "One provides a directory of providers so that a user interface allows easy provider selection ..."
> Section 9.1, get rid of extra "a" in the section "...a country code suitable for display, with a corresponding "a" URI ...
> Section 9.2, get rid of extra "the" in the first sentence "...provider configuration "the" using a simple..."
> Section 9.4 - Get rid of the redundant word "Sections" in the first sentence "The interfaces in "Sections" Section 9.1 ..."
>  
>  
> Thanks.
>  
> Eugene Christensen.
>  
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked] <mailto:[email-masked]> or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.
>  
> From: Rum <[email-masked] <mailto:[email-masked]>> On Behalf Of Brian Rosen
> To: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Feb 2021 15:02:46 -0500

Hi Eugene,

On 2/9/21 11:27 AM, Eugene Christensen wrote:
> *Substance Comments*

Brian and I discussed this and I was the one proposing this. This is a 
requirement on the RUE, not the provider.  It puts the decision of which 
to use on the provider side. It provides a way forward to a future world 
where not everybody has v4. Since this is a spec for devices that don't 
yet exist it makes sense to me to do it.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Feb 2021 13:41:52 -0500

Eugene

Did these answers satisfy you?  Do you have any open issues?

Brian

> On Feb 9, 2021, at 3:02 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Hi Eugene,
> 
> Brian and I discussed this and I was the one proposing this. This is a requirement on the RUE, not the provider.  It puts the decision of which to use on the provider side. It provides a way forward to a future world where not everybody has v4. Since this is a spec for devices that don't yet exist it makes sense to me to do it.
> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Feb 2021 13:46:14 -0500

Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP credentials
c) STUN/TURN credentials

The current draft treats them all as identical.  Is there a reason to make them separate?  My VoIP accounts have only one set.  I’m okay adding a separate SIP/STUN/TURN credential returned in the config file, protected by the actual user login credentials, if that is really useful.  Maybe it could be optional, and if not provided, the userid/password is used for everything.

Brian

> On Feb 9, 2021, at 9:41 AM, James Hamlin <[email-masked]> wrote:
> 
> Jim
> 
> On Feb 9, 2021, at 4:42 AM, James Hamlin <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Brian
>  
> purplevrs.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,lHszv64tt0_3vwBuoJun-nx4WCNcqTTmH1eRB5etseOPqyLqiTiUBcbLjJjOw8-LNqVFBp6ocg3-Ex0Yf1VQWGob1gzB639RyM04xTf4VvBF48mh&typo=1>
> From: Rum <[email-masked] <mailto:[email-masked]>> on behalf of Brian Rosen <[email-masked] <mailto:[email-masked]>>
> until the htmlized version and diff are available at tools.ietf.org <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2ftools.ietf.org&c=E,1,4v8fNKuLbBZftOaLG3HnWCDj7G3Vbuozoee0zefXWUutbhixY92rsdDUAd3VVvv1kqgejs55PeHXY1nDWRpLsPcQL-JowBCzPJLzJiV4ImsnRv65oRxmnGYz4Dc,&typo=1>.
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Feb 2021 13:50:14 -0500

Paul, you wanted to talk about separate credentials for CardDAV.  If that’s useful, I can have them (optionally) returned in the provider config file.  It wasn’t clear to me how useful that is, but it’s not hard, and if it’s optional, it’s pretty easy to implement.

Brian

> On Feb 22, 2021, at 1:46 PM, Brian Rosen <[email-masked]> wrote:
> 
> Brian
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2021 17:24:32 -0500

On 2/22/21 1:50 PM, Brian Rosen wrote:
> Paul, you wanted to talk about separate credentials for CardDAV.  If 
> that’s useful, I can have them (optionally) returned in the provider 
> config file.  It wasn’t clear to me how useful that is, but it’s not 
> hard, and if it’s optional, it’s pretty easy to implement.

I think there are two distinct cases here:

1) carddav server administered by the provider. separately configured 
per provider, as part of the configuration. In this case I can see no 
reason why it would need to be separate credentials from sip, etc.

2) an independent carddav server (e.g., Google) associated with the RUE, 
and used across providers. The credentials for this would need to be 
distinct. Also, probably totally out of scope for this spec. But if I 
were implementing a RUE I would want to include this.

	Thanks,
	Paul

> Brian
> 
>> On Feb 22, 2021, at 1:46 PM, Brian Rosen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Brian
>>

---

From: James Hamlin <[email-masked]>
Date: Tue, 23 Feb 2021 14:58:17 +0000

Brian

I think having the flexibility to optionally return separate SIP/STUN/TURN credentials could be useful. Optionally returning a refresh token which the RUE would hold in place of the user login password would also be useful, as it would mean the login password would not have to be stored after the first configuration; refreshing an expired configuration would be done with the refresh token.

James

James Hamlin
Contractor

________________________________
From: Brian Rosen <[email-masked]>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim Malloy; [email-masked]
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt

There are:

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

Jim

Best Regards

James

James Hamlin
Contractor
purplevrs.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,A7YjAZQyJSuch-Py5Wo_oExHa1fYL1pPanm4Na7Vl-k3R7dMrCIRRNYIx6Rk1PlSt3hcHjCcLwzZ8H6TVOu8tBqv_Jb9__CMRu_4aioIWw,,&typo=1>

From: Jim Malloy <[email-masked]<mailto:[email-masked]>>

James –

Thanks,

Jim Malloy

From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Rosen
Sent: Tuesday, February 9, 2021 8:44 AM
To: Hamlin, James <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

Brian

Brian

Best regards

James

James Hamlin
Contractor

Brian

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Feb 2021 10:09:01 -0500

Okay, I’ll add optional SIP/STUN/TURN credentials.  

Tell me a little more about how you think the refresh token would work.  Would it allow a device to have a power failure, come back, and accept incoming calls?

Brian

> On Feb 23, 2021, at 9:58 AM, James Hamlin <[email-masked]> wrote:
> 
> Brian
> 
>> On Feb 9, 2021, at 9:41 AM, James Hamlin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Jim
>> 
>> purplevrs.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,A7YjAZQyJSuch-Py5Wo_oExHa1fYL1pPanm4Na7Vl-k3R7dMrCIRRNYIx6Rk1PlSt3hcHjCcLwzZ8H6TVOu8tBqv_Jb9__CMRu_4aioIWw,,&typo=1>
>> From: Jim Malloy <[email-masked] <mailto:[email-masked]>>
>> To: Hamlin, James <[email-masked] <mailto:[email-masked]>>

---

From: James Hamlin <[email-masked]>
Date: Tue, 23 Feb 2021 17:06:54 +0000

It's been a while since the refresh token was discussed; but if it is returned in the configuration, the RUE should replace/overwrite it's stored copy of the user password with the token. The token would then be valid where the user password was valid initially. Similarly, in further refreshes of the config, if a refresh token is returned, it replaces the previous token. That wouldn't have any effect on the ability to recover from power failure.

James

James Hamlin
Contractor

Sent: 23 February 2021 15:09

Brian

On Feb 23, 2021, at 9:58 AM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

Brian

James

James Hamlin
Contractor
purplevrs.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,OxXdApoolhezgGoqbrvN6MFrlh0ZKJnSlblcKRQrFhqz_l1wb7YR4HZHu5OGAkq854LrySBoiFAbJWndXecF4vmM0hyffKdJoO6zaa4O&typo=1>

________________________________
From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim Malloy; [email-masked]<mailto:[email-masked]>
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt

There are:

Brian

Jim

Best Regards

James

James Hamlin
Contractor

James –

Thanks,

Jim Malloy

Brian

Brian

Best regards

James

James Hamlin
Contractor

Brian

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Feb 2021 12:21:20 -0500

Is the token a username/password equivalent (meaning, does it use the normal SIP REGISTER authentication)?
As long as it’s valid until replaced, that’s OK with me.

Brian

> On Feb 23, 2021, at 12:06 PM, James Hamlin <[email-masked]> wrote:
> 
> 
>> On Feb 23, 2021, at 9:58 AM, James Hamlin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Brian
>> 
>> purplevrs.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,OxXdApoolhezgGoqbrvN6MFrlh0ZKJnSlblcKRQrFhqz_l1wb7YR4HZHu5OGAkq854LrySBoiFAbJWndXecF4vmM0hyffKdJoO6zaa4O&typo=1>
>> From: Brian Rosen <[email-masked] <mailto:[email-masked]>>
>> Cc: Jim Malloy; [email-masked] <mailto:[email-masked]>

---

From: James Hamlin <[email-masked]>
Date: Tue, 23 Feb 2021 17:48:49 +0000

I was assuming the refresh token would simply stand in for the password literally. That said, when the idea was previously discussed, the token would have solely been used in authentication for config retrieval, as SIP would use the password set by configuration. It has been a long time since the refresh token was discussed so others might remember more.

I think the provider needs to keep one token valid until the next is first used or make it valid for much longer than the configuration lifetime.

James

James Hamlin
Contractor

Sent: 23 February 2021 17:21

Brian

On Feb 23, 2021, at 12:06 PM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

James

James Hamlin
Contractor
purplevrs.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,RQME2r1XQYLP5mwRPwDI6t1Y1MxyEakofyy6nmkXN7qNudXguSsmykk-HM8SotP3vuRt3Q1aWIKM0q9XKX9KdO2JiiAoahHipT9OC9rOjQemPnVpew,,&typo=1>

Brian

Brian

James

James Hamlin
Contractor

There are:

Brian

Jim

Best Regards

James

James Hamlin
Contractor

James –

Thanks,

Jim Malloy

Brian

Brian

Best regards

James

James Hamlin
Contractor

Brian

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Feb 2021 13:39:06 -0500

Okay, let’s walk through how this is used:
1. The user creates a new account.  They create a username/password for the account.  That is stored in the device
2. The device retrieves configuration using the username/password
3. Configuration may contain a refresh token.  This is a password.  The token is used instead if the actual password, but with the actual username, to do SIP/STUN/TURN authentication.
4. The refresh token is used until the config retrieval changes it.

Is that right?  Can you explain why this is better than just using the account username/password?

Brian

> On Feb 23, 2021, at 12:48 PM, James Hamlin <[email-masked]> wrote:
> 
> 
>> On Feb 23, 2021, at 12:06 PM, James Hamlin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> purplevrs.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,RQME2r1XQYLP5mwRPwDI6t1Y1MxyEakofyy6nmkXN7qNudXguSsmykk-HM8SotP3vuRt3Q1aWIKM0q9XKX9KdO2JiiAoahHipT9OC9rOjQemPnVpew,,&typo=1>

---

From: Eugene Christensen <[email-masked]>
Date: Tue, 23 Feb 2021 21:40:00 +0000

Thank you Brian and Paul for your responses.

Regarding IPv4/IPv6, I can see your point that a path forward is needed due to the diminishing availability of IPv4 addresses.  Thanks Paul for pointing out that the IPv6 requirement would be on the RUE only and servers can continue to run on either/both (with a gateway if necessary).  This sounds like an appropriate approach.

Regarding section 9.2 and the vetting of new users, when I read through it initially, my assumption was that the process was one that would be completed in real time.  It sounds like that must not be the intent.  I wonder if it might be helpful to have something that calls that out; that it isn’t intended to be synchronous for a new user but rather that it provides a starting point for getting registered with the provider?

BTW, thank you for adding that an API key MAY be used.

Eugene.

From: Brian Rosen <[email-masked]>
Sent: Tuesday, February 9, 2021 9:54 AM
To: Eugene Christensen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

[EXTERNAL]

On Feb 9, 2021, at 11:27 AM, Eugene Christensen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Substance Comments

  *

  *

  *

Typo Comments

Thanks.

Eugene Christensen.

Brian

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Feb 2021 16:45:00 -0500

How about:

The new user signup contact URI may only initiate creation of a new account.  Various vetting, approval and other processes may be needed, which could take time, before the account is established.  The result of creating a new account would be a username and password, which would be manually entered into the RUE device to allow connection to the Provider.

> On Feb 23, 2021, at 4:40 PM, Eugene Christensen <[email-masked]> wrote:
> 
> To: Eugene Christensen <[email-masked] <mailto:[email-masked]>>
> On Feb 9, 2021, at 11:27 AM, Eugene Christensen <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Brian, 
>  
> https://www.ietf.org/archive/id/draft-ietf-rum-rue-04.html <https://www.ietf.org/archive/id/draft-ietf-rum-rue-04.html>
>

---

From: Eugene Christensen <[email-masked]>
Date: Tue, 23 Feb 2021 21:50:19 +0000

That sounds reasonable.

Thanks.
Eugene.

From: Brian Rosen <[email-masked]>
Sent: Tuesday, February 23, 2021 2:45 PM
To: Eugene Christensen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

[EXTERNAL] How about:

On Feb 23, 2021, at 4:40 PM, Eugene Christensen <[email-masked]<mailto:[email-masked]>> wrote:

Eugene.

To: Eugene Christensen <[email-masked]<mailto:[email-masked]>>

[EXTERNAL]

Hi Brian,

Substance Comments

  *

  *

  *

Typo Comments

Thanks.

Eugene Christensen.

Brian

Begin forwarded message:

Abstract:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2021 12:41:39 -0500

Brian,

> Thanks for the comments.  Responses inline

I just realized I never replied to this.

>> On Feb 6, 2021, at 5:08 PM, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Brian,
>>
> Yeah, the RUE doesn’t directly deal with them.  They go to the default 
> provider, who forwards them to the RUE.  Do we need to say that?

Hmm. Not sure. Perhaps not, since the RUE has no role in it. Perhaps 
somewhere we could say *that* - that handling of inbound dial-around is 
out-of-scope for this document.

> Can we say that if multiple proxies are mentioned the provider MUST 

You mean that if *one* proxy is configured then outbound is optional, 
but if two or more are configured then outbound is required?

ISTM that in the absence of outbound the way to utilize multiple proxies 
is undefined. I can think of two possibilities:

1) All included in the Route header. I don't see any reason to have
    this as a feature. (If needed it can be accomplished with
    Service-Route.)

2) The RUE uses them as alternatives. This can be accomplished using
    DNS, so doing via explicit configuration seems silly.)

Unless there is some other compelling way to use multiple proxies 
without outbound then I am fine with reserving this for use with outbound.

>> arrive from the proxy. But if outbound *isn't* used then there isn't 
>> any obvious way for the RUE to figure this out
>>
>> (I think there may be some resistance to use of outbound in mobile 
>> RUEs because it can significantly increase the power demand.)

In the absence of outbound I still don't see how the RUE can restrict 
the source of incoming requests. Perhaps we simply say that if using 
outbound then requests MUST only be accepted via the outbound connection.

But note that is further complicated if the RUE is connected to multiple 
providers. I think the wording to cover this may be tricky. But we need 
to sort out what we want the rules to be before deciding how best to 
state them.

>> While people may have an intuitive understanding of it, they may not 
>> all understand it the same way.
>>
>> for 0<=i<N. (There will be implications on how the spec for a new 
>> minor version is defined in order to make it feasible for 
>> implementations to make this guarantee, but we need not go into that.)
> I reworded it to say:
> To achieve backwards compatibility, implementations MUST ignore any 
> object members they do not implement and minor version definitions SHALL 
> only add objects, non-required members of existing objects, and 
> non-mandatory-to use functions and SHALL NOT delete any objects, members 
> of objects or functions.  This means an implementation of a specific 
> major version and minor version is backwards compatible with all minor 
> versions of the major version.

As I noted above, defining the requirement for backward compatibility is 
distinct from deciding how revisions should be written to facilitate 
that compatibility.

I agree with the first part of your statement above, but suggest a 
slight rewording:

"To facilitate backwards compatibility, implementations MUST ignore any 
object members they do not implement."

The other part isn't a requirement on implementation of this spec. It is 
a requirement on how future revisions of this spec are to be written. I 
don't think normative language is appropriate here. But I think it could 
be reworked as a note for future revisions:

"NOTE: In the future, when the schema for a new minor version is written 
it should only add objects, non-required members of existing objects, 
and non-mandatory-to use functions and should not delete any objects, 
members of objects or functions.  Then an implementation of that new 
minor version will automatically be backwards syntactically compatible 
with the predecessor."

(There could be behavior changes not reflected in the schema that also 
impact backward compatibility. E.g., deprecation of versions of protocols.)

> Yes, the version mechanism has to remain available and at least 
> backwards compatible to V1.  I don’t think that is a problem, and there 
> are no protocol police if some future work group breaks the assumption.

At the least, I think we should add the requirement to ignore unknown 
object members, so that revisions to the version list are possible.

> Sign language for interacting with the RUE user

[NOTE: I am woefully uninformed about language coding, so I am likely to 
be saying something stupid here.]

I note that the example codes "en" and "es", which I think are spoken 
and/or written language codes.

ISTM that there are likely to be reasons to code sign language, spoken 
language and written language. But we may need to specify exactly what 
coding a particular language is promising.

Can some providers please chime in here? What degrees of freedom do you 
have in this regard?

>> offer special UI for these, or not. If not then I guess it would have 
>> to make this configuration info available somehow. Else these things 
>> could be pre-populated in the address book. (I think that is how 
>> providers do it today.)
> For the help desk, I wanted this to not require an existing relationship 
> with any provider.  So it’s a SIP URI that doesn’t need a proxy that 
> establishes a video call to a sign-language capable helper.

One point I was making here is that we don't currently provide any 
specification for calling by sip URL - only by phone number. If the 
config specifies a phone number then we have enough defined for the RUE 
to implement this. If we specify a URL here then we need to add some 
text elsewhere for initiating calls by URL, even if that is only for 
configured URLs and not for ones entered via the GUI.

> For dial around, it’s whatever it takes to video call point-to-point 
> using the default provider.  In the US that would be a 10 digit number 
> that was in the iTRS Directory, but that might be different in some 
> other country

For frontDoor, same comment as above for helpdesk.

For oneStage, while the provider config includes a oneStage dialaround 
URL and Figure 1 shows using that in a Route header, I can find no 
normative text specifying the inclusion of that URL in a Route for a 
dialaround call. I guess it should be added to section 5.2.2.

> I can fix that, but I want to ask if there is an actual use case for it? 
>   Why would a provider have more than one URI for a particular 
> user/phone number?  Happy to fix it, but we would need to say how the 
> RUE uses it.  Incoming is clear (accept calls from any configured proxy).

I'm baffled here. If using RFC5626 (outbound) then normally the UA will 
be using the same proxies for both inbound and outbound traffic. 
Multiple proxies configured for redundancy. And in any case your example 
already is showing multiple proxies although the schema doesn't agree.

>> Finally, a style issue: The keywords are named in a mixture of 
>> camelCase and hyphenated words. (Like snake-case but with hyphens 
>> instead of underscores. I don't know of a name for this.) I think we 
>> need to pick a consistent style.

I don't care either. If you like camelCase then that is fine.

>> I'll aim to come back after studying up on it.

...

>> password, it should notify the user, so the user can actively change 
>> the password and update the RUE. Of course the provider can do this 
>> is required on his part to restore service. But 401 or 404 responses 
>> are probably sufficient to trigger this.)
> Since, at the moment, there is no mechanism other than manual entry for 
> the RUE to learn the username and password, I think all of this is also 
> manual.  We could add mechanism for a password update if that’s helpful 
> without the initial password capture, but that would only be secure if 
> it used the old password to authenticate to update to a new one.

I have become convinced that it can be left up to the provider to notify 
the user in advance when there is an impending requirement to revise the 
password. There are a variety of mechanisms they can use to do that, 
including video mail that could be signaled through the RUE.

In the case of a need for provider to force a credential change without 
advanced notice, the worst case will end up with the RUE being forced to 
ask the user for new credentials that the user will have to learn out of 
band some way. A provider can probably find a way to avoid the worst of 
this. For instance, it might not revoke an existing registration, but 
still challenge an outgoing request for new credentials. But this 
becomes a quality-of-implementation issue.

BTW, ISTM that the best way to do the manual configuration of pw is via 
the normal case of a request that has been sent to server, challenged by 
the server, and then the challenge being exposed to the user in the GUI.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 25 Feb 2021 09:20:55 +0100

I don’t think RUE should invent it’s own authentication handling.

For information on token handlings, including access tokens and refresh tokens, please refer to Oauth2.
That way we can simply reuse what’s existing.

/O

> On 23 Feb 2021, at 18:06, James Hamlin <[email-masked]> wrote:
> 
>

---

From: James Hamlin <[email-masked]>
Date: Thu, 25 Feb 2021 08:49:50 +0000

Brian

Having consulted internally, we are content if support for separate passwords and tokens is dropped, as providers could always allocate users separate RUM RUE passwords if required.

Also we think the refresh token, as it was previously discussed, would have been the result of using OAuth. So OAuth would have provided a token that allowed the RUE to refresh its config without retaining the user password; which fit's with Olle's suggestion.

James

James Hamlin
Contractor

Sent: 23 February 2021 18:39

Brian

On Feb 23, 2021, at 12:48 PM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

James

James Hamlin
Contractor
purplevrs.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,k9APnAGGrsVbugFZpxKFp1wym7cEPtZeKy_n31zZFISBgev0Lmw7SmmVKIUmNreeXQdUpinsfevSRZm4gdvbFQLQHgxBhpLLqnOdJ5SZReqHOSnvwLu0zaTC&typo=1>

Brian

James

James Hamlin
Contractor

Brian

Brian

James

James Hamlin
Contractor

There are:

Brian

Jim

Best Regards

James

James Hamlin
Contractor

James –

Thanks,

Jim Malloy

Brian

Brian

Best regards

James

James Hamlin
Contractor

Brian

Begin forwarded message:

Abstract:

---

From: Eugene Christensen <[email-masked]>
Date: Thu, 25 Feb 2021 20:25:33 +0000

Hi Brian.

I’ve been reviewing draft 4 some more and discussing it internally and wonder about the following:

Section 5.2.5 Emergency Calls
It seems that since the RUE could be on many different device types, including non-nomadic devices such as desktops, we should require the RUE to provide a way to for the user to input their address.  Without such, it will require the CA to ask the caller in an emergency situation for their location.  The caller may be having issues at the time of the call and may be limited in their ability to provide such information as their location.  For this reason, I think the RUE should be required to implement UI to obtain this ahead of time and also to be updateable.

Section 6.2 Text-Based Communication and WebRTC
Given that WebRTC does not yet support T.140 and a transcoder will be required (as already noted in section 6.2).  If the endpoint is a WebRTC solution, I wonder if the transcoder should be required of the developer of the WebRTC solution and not the providers.  I believe language expressing this should be added to this section until such time that WebRTC has an acceptable solution for T.140.

Brian

Begin forwarded message:

Abstract:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2021 17:45:39 -0500

Eugene,

> *_Section 6.2 Text-Based Communication and WebRTC_*
> 
> Given that WebRTC does not yet support T.140 and a transcoder will be 
> required (as already noted in section 6.2).  If the endpoint is a WebRTC 
> solution, I wonder if the transcoder should be required of the developer 
> of the WebRTC solution and not the providers.  I believe language 
> expressing this should be added to this section until such time that 
> WebRTC has an acceptable solution for T.140.

I don't think there is any implication here that the providers would be 
required to provide that transcoding.

Putting up a RUM-compatible solution that uses WebRTC will require 
running a service somewhere that has a WebRTC interface on one side and 
a RUM-compliant interface on the other side that connects to providers. 
(In this case the service is actually the RUE, and WebRTC is simply part 
of the UI implementation in the RUE.) That service will have to provide 
a T.140 transcoder in order to pass the T.140 to the provider.

It is unclear to me who would build and operate such a service. We might 
imagine some future day when the providers might themselves host such a 
server as part of their offering. Conceivably some provider might do 
that on their own because they see it in their best interest. But it is 
out of scope for the current spec.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 26 Feb 2021 07:51:11 +0100

> On 25 Feb 2021, at 23:45, Paul Kyzivat <[email-masked]> wrote:
> 
> Eugene,
> 
> I don't think there is any implication here that the providers would be required to provide that transcoding.
> 
> Putting up a RUM-compatible solution that uses WebRTC will require running a service somewhere that has a WebRTC interface on one side and a RUM-compliant interface on the other side that connects to providers. (In this case the service is actually the RUE, and WebRTC is simply part of the UI implementation in the RUE.) That service will have to provide a T.140 transcoder in order to pass the T.140 to the provider.
> 
> It is unclear to me who would build and operate such a service. We might imagine some future day when the providers might themselves host such a server as part of their offering. Conceivably some provider might do that on their own because they see it in their best interest. But it is out of scope for the current spec.

When talking about WebRTC there is always confusion. There’s a library called WebRTC and a set of standards.

Where in the set of standards does it forbid T.140? I don’t think that the assumption that IETF/W3C WebRTC
doesn’t support T.140 is correct.

That browsers hasn’t implemented support is another issue.

/O

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Feb 2021 11:06:40 -0500

Thanks for these comments.

With respect to emergency calls, you are limited by FCC regulations in the US, I believe, although there are 3rd party entities that supply extra location information from Google and Apple after the call is received at a PSAP.  I think you have to use a location collected (and verified) as part of account establishment.  Typically there is a website that updates this as necessary.  I don’t like that as the answer, but I think we’re stuck with it.  Other countries may have more flexibility.  To be sure, the device MAY add a location via the Geolocation header.  It’s just that the provider MUST add a location.   I can make that clear in the text.

The thing about WebRTC is that it does specify T.140, but transport is in the data channel.  The RUE spec is T.140 in SDP.  The transport adapter would be the RUE device and not the provider. I can try to improve the wording there to make it more clear.

Brian

> On Feb 25, 2021, at 3:25 PM, Eugene Christensen <[email-masked]> wrote:
> 
> Hi Brian.
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Feb 2021 11:09:36 -0500

What do you want to do with OAuth?  Make it mandatory, optional or not included?  I’m happy with any of these.  If it is included, is it used for authentication to the configuration service, the SIP/STUN/TURN services or both?

Brian

> On Feb 25, 2021, at 3:49 AM, James Hamlin <[email-masked]> wrote:
> 
> Brian
> 
>> On Feb 23, 2021, at 12:48 PM, James Hamlin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> purplevrs.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fpurplevrs.com%2f&c=E,1,k9APnAGGrsVbugFZpxKFp1wym7cEPtZeKy_n31zZFISBgev0Lmw7SmmVKIUmNreeXQdUpinsfevSRZm4gdvbFQLQHgxBhpLLqnOdJ5SZReqHOSnvwLu0zaTC&typo=1>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2021 12:09:13 -0500

> That browsers hasn’t implemented support is another issue.

That browsers haven't implemented it is *the* issue.

Since webrtc has defined T.140 over data channel it is hard for me to 
imagine what would them to support it directly over RTP. There is no way 
to get there from here.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 26 Feb 2021 18:53:45 +0100

> On 26 Feb 2021, at 18:09, Paul Kyzivat <[email-masked]> wrote:
> 
> Since webrtc has defined T.140 over data channel it is hard for me to imagine what would them to support it directly over RTP. There is no way to get there from here.
> 
I can accept that, but we can’t write that “WebRTC does not support T.140”. If you write your own implementation nothing stops you from implementing T.140 in RTP or over data channel.

/O :-)

---

From: Eugene Christensen <[email-masked]>
Date: Fri, 26 Feb 2021 20:57:08 +0000

For emergency calls and the ability to add a location on the device, we need to keep in mind that a customer could have multiple devices.  Somehow, we need to tie the physical address to each device.  Perhaps by MAC address, I’m not sure how each of the current VRS providers do this.  Also, it would be good to keep the ability to update the address directly on the device, as it is now.  In fact, since we need to possibly register address on multiple RUEs for the same user, doing so on the device seems to be a natural solution.

Thanks.

Eugene.

From: Brian Rosen <[email-masked]>
Sent: Friday, February 26, 2021 9:07 AM
To: Eugene Christensen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

[EXTERNAL] Thanks for these comments.

Brian

On Feb 25, 2021, at 3:25 PM, Eugene Christensen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian.

Brian

Begin forwarded message:

Abstract:

---

From: Eugene Christensen <[email-masked]>
Date: Fri, 26 Feb 2021 20:58:40 +0000

I may have mis-spoke about WebRTC and support for T.140 but I believe everyone has understood the challenge.  As long as it is clear that the RUE device is responsible for transcoding, not the provider that would be satisfactory.

Thank you.

CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked] or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Olle E. Johansson
Sent: Friday, February 26, 2021 10:54 AM
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked]; Olle E Johansson <[email-masked]>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

[EXTERNAL] 

>> Where in the set of standards does it forbid T.140? I don’t think 
>> that the assumption that IETF/W3C WebRTC doesn’t support T.140 is correct.

/O :-)