Accessible Platform Architectures Working Group Teleconference

02 Oct 2019


jasonjgw, janina, Joshue, SteveNoble, Joshue108


Real-time communication accessibility.

<scribe> scribe: Joshue108

<discuss WebEx foibles>

JW: We are looking at RTC accessibility issues.

We need to review the IETF draft

I've spent some time on it, we can discuss.

Then we need to talk about progressing the doc to FPWD.

This seemed to be the concensus, that this work is published.

Happy to take comments.

JS: That sounds correct, we have a communication from the WebRTC group overnight.

JW: I did read there was discussion in response to joint meeting with APA?
... Correct?

<jasonjgw> Josh: the APA use cases appear to have been brought to the attention of the IETF working group working on the protocol.

JB: I've a note from Dom, that came from last week.

<gives overview>

About how RTT can be used with WebRTC etc

I think this is what we need.

JB: I saw an RTC issue on APA agenda today..

Dom said this could be turned into a PR - I've got.

<Zakim> Joshue, you wanted to ask what text Judy is reading

JB: I may just forward that to the RQTF list.

JW: Nothing confidential?

JB: Just checking..

JOC: Thats useful Judy.

JW: Thanks for clarification that the existance of the use cases is known to the IETF group.
... I will give some comments on https://tools.ietf.org/html/draft-holmberg-mmusic-t140-usage-data-channel-02
... I think I'm not the right person to review the protocol level docs, with many RFC level refs.
... It uses the WebRTC data channel and it is clear that unlike RTP it is meant to be a reliable, not TCP - the other one.


JW: This creates a data channel and they are defining the charactherisics of the Real time negotiaion - directionality etc send only, recieve only, bi-directionality etc.

You can define the language, and they can be re-negotiated during the session.

You can also re-nog the rate that the characthers are sent.

JW: Characther set defined elsewhere.
... Likely, uni-code format.

They do say there may be future provisions to indicate source of the strings etc.

JW: There is also a statement saying some negotiation parameters are not handled via a known API.

Thats one for W3C.

JW: Haven't looked at what character set is supported etc. But diff scenarios can be supported in the implementation, bi-directionality etc.
... Thats most of what I got.

<jasonjgw> Josh: wishes to identify any protocol issues that might exist here.

<jasonjgw> It wasn't clear to Josh what needs to be included in WebRTC.

<jasonjgw> Josh: next version use cases of WebRTC need to cover RTT use cases.

JS: I should take that up!

I think the WebRTC Next Gen spec is the place where the support for diff kinds of RTT need to happen.

For deaf community a la emergency and the wider world use cases.

That is whats behind the IETF RTT spec.

JS: Our response is necessary but insufficient.

Use cases may be restricted, so we need to be careful and consider how they are presented to remain intelligible.

The WebRTC group did say they are aware of the FCC move towards RTT.

There were members involved.

It is just not supported in this version, as the IETF have not closed on their RFC.

Once done they can take up that..

jB: The part that gets me is that the deaf community is saying there are polyfill implementations.

I don't see it in Doms draft language.

JS: I don't think we have a disagreement.
... I think we are saying the same thing..

JB: Its one thing to say what we can't do for now and explain why..

but when there are real world implementations we should capture what is happening

+1 to Judy

JS: That should be in the supplementary doc.

JOC: I think we should discuss Doms text.

JS: I have a comment about Jasons input..

Didn't add up - the indication of language and locking of a characther set.

If I'm IMing in Russian but need to use non Cyrillic scripts, whats that?

JW: It could be UTF-8 or other Uni-code..

JS: I'm going to assume there is logic here - UTF-8 may cover the languages we know.

JB: Can I ping Dom?

JW: Most welcome.

JS: I want to talk with Personalisation TF about AAC symbols.

Do we need that in this channel if we think WebRTC will define web based comms.

We need to include these use cases.

That wont be in ??

<introductions around table>

JB: I forwarded the note from you, bernard and Harald - it is precise, so I need the group to make descion on the language.

I was hoping the polyfill JS approach was documented - if we had agreement I could ask Christian and others to provide detail on those implementations.

Not seeing that recognition here - if we can refine this on the call - that would be great.

<Dom intro>

DHM: I don't have this reference but can check with Bernard.

I understood that your contacts, like Christian has set up these gateways between WebRTC clients and other sources.

There is also ?? in Erikson who may know of other solutions.

What we are describing in this note, is not something that directly intersects with w3C specs.

It is a server side component that can be plugged into a WebRTC client.

So I wasn't expecting to go to that level of detail.

JS: We would like to due to deaf users using Baud type coms and they are migrating to this type of thing.

We want to make sure this is supported by anyone using these things.

It is critical for 911 etc coms.

Also if WebRTC does not support it that will be a problem for its success.

I heard in our meeting that WebRTC spec 1.0 cannot say more than this informative note as IETF has NOT finished work on RFC.

But it has been suggested that WebRTC 2.0 could say more.

Criticiality of text based comms is one thing, but when it is intergrated in WebRTC x, there are other use cases that will need to be supported on a client configuration.

Successor to IRC for example - thats useful for audio and video for notes and URL sharing etc.

So the RFC may not be contemplating but needs to not interfere with it.

DHM: IMO we need to distinguish from RTT in the general sense, is clearly doable, with WebSockets and WebRTC data channels.

How that is interfaced to the user, can be config via application.

There may be value in browser configs for this but doable at application level.

Doing a browser based standardisation needs further discussion.

The critical point relating to emerging use cases in the RFC sense that the FCC requires.

For that the IETF protocol stack does not provide this ??

It is not embedded in what the clients are built upon.

What we are trying to describe in our proposed note, is that it is relatively easy to get RTT in and transmit it to a data channel.

You would require a gateway to do this over WebRTC today..

You would need a plug in via a gateway - adding this would translate via client to build interface.

Straightforward - packet transformation.

DHM: What I don't know is if such gateways are developed as product or deployed.

Also what lessons have emerged from that.

We are trying to express in the note, given how things work WebRTC does allow a gateway to be put in place.

In the IETF this gateway could be standardised, so there is a single clear way to set up a gateway and make it easier to deploy.

OR directly expose RTT as a new data source.

In webRTC clients, browsers.

JS: We are not in disagreement, we need to look at this language you have sent Judy.

+1 to Janina.

JW: You taking this to APA today?

JS: Will do.

JB: You need a response later this week, I need to clarify how we can loop in how people are using polyfills.

This does need to be reflected.

+1 to Judy

DHM: The gateways are not meant to be temporary, if they work, they work.

Future versions of the protocol may make it easier to deploy.

There may not be a need in the future if we can expose directly in WebRTC clients.

Don't know if gateway approach is less robust than direct client.

JB: Thats helpful, still looking for clarification point on how to get others to look at this before APA reviews.

JS: This is an informative note? Everything we tweak is editorial?

DHM: We could change some informative edits, before proposed rec.

Would need to go to director..

JS: I've had converstaions like this in Japan - a la editorial changes, they can be done right up to TR.

Maybe we can finish, while you are in CR.

We do want to be confident that it is close in CR.

<makes sense>

DHM: How much time do you need?

We have some delays..

If it is next week, we could make it work.

But don't want it to be open ended.

<Zakim> Joshue, you wanted to say can we discuss Doms draft language?

<Zakim> janina, you wanted to discuss two issues: lang/charset and also necessary but insufficient on use cases

JB: My last discussion was two weeks ago, I don't know if they can look at this quickly.

There's been nothing to communicate back on. Lets be deliberate here.

DHM: We could have something that APA would be happy with as default text, if we dont get feedback by then?

JB: Sounds good.
... Can I get something post APA call to share?

Right now, I dont see anything explicit that speaks to what we are looking for.

JS: I've not read it yet either.

APA descision policy requires a minimum of two business days, our earliest decision would be by the weekend.

JS: I'll cc Dom and Judy and we will move it along.

DHM: We welcome new language that would be more usable.

<all thanks to Dom>

JW: This is a process and we are in the short term, and we will keep looking at the long term issues.
... The AAC symbolsets issue need to be covered in the use cases doc.

<jasonjgw> Josh: acknowledges the importance of the text currently under discussion.

<jasonjgw> Josh: there is a use case for personalized symbol sets for identifying functions in WebRTc-enabled clients.


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/10/02 14:02:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/scipts/scripts/
Default Present: jasonjgw, janina, Joshue, SteveNoble
Present: jasonjgw janina Joshue SteveNoble Joshue108
Found Scribe: Joshue108
Inferring ScribeNick: Joshue108
Found Date: 02 Oct 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]