Sangwhan: unclear what hardware they want to support with this

Amy: they list negative signals from Gecko and Webkit

Sangwhan: hareware that uses is is either industrial or 20 years old

Dan: often eg. if you talk to people at Intel they're talking about industrial things like tractors. Is this an industrial use case, or a maker community use case? Would be interesting to know. They're not talking about specific platforms or devices in their motivation.

Sangwhan: I have a multimeter that uses RFCOMM. It would be cool if that worked, but seems like a lot of overhead for the web platform.

Dan: why isn't this happening in the web bluetooth cg?

[digging into history]

Sangwhan: HID makes sense because webusb can't see it unless you kick it into a special mode, disconnect and reconnect. Serial makes sense because of how OS treats it. Web bluetooth for same reasons will not really make sense, if the device is paired it's paired as a serial port. I don't know how it would work if you did the pairing from the browser. Still would be OS pairing. Ultimately I'm unconcinced about use cases

Dan: we could ask them to be concrete about devices they propose need to be connected to the web.

Amy: there are a lot of use cases in the various standards position threads from people in the community

Sangwhan: very specific use cases with a lot of baggage for the web platform

Dan: sympathetic to use cases from maker community

Amy: tantek's comment

Dan: Thomas has come back with [some feedback]https://github.com/w3ctag/design-reviews/issues/854#issuecomment-1659895741).

Max: if you look into the lego example - they use web bluetooth API - not serial API... so from some perspective it's not a justification for web serial for bluetooth - because that use case is not described. They use 2 APIs - one is web bluetooth API - normal bluetooth to connect the web browser to the LEGO hub - the other option is to use web serial API connection – this requires USB cable. In this use case they don't require web serial API over bluetooth. In my view if you already have bluetooth why not just use bluetooth to do the connection?

Max to ask them to ask them to clarify

Sangwhan: the permission model - serial needs permission and bluetooth needs permission - those are separate. How does that work? Do you need both bluetooth and serial at the same time? The permission gate would be at a different API surface trigger... couldn't see how that's supposed to work. There might be cases where you want to grant browser enumeration of serial devices but not bluetooth serial?

Yves: you will enumerate on bluetooth and then it ..

Dan: feels to me this is something the browser should be doing - seems like this is a bluetooth thing but it's using the serial profile so browser exposes it using the webserial api to the application and as far as the app is concerned it's a serial device

Sangwhan: so browser does the initial... pairing process.. at the point you paired.. is that required before you can enumerate a serial port?

Dan: in that case.. most devices have a mechnism to pair a bluetooth thing that's built into the OS. Why not have the device do the pairing? Abstract away the fact that's bluetooth. Why does the web application have to know that it's bluetooth? Why doesn't it just see it as a serial device and bluetooth is hidden away

Sangwhan: that's what I think I'm reading from the explainer. There's an implication that the bluetooth connection has already been made and that i'tll be exposed a serial, but who does the bluetooth pairing? If it's the browser.. what is the lifecycle that goes from bluetooth pairing to this. I don't undderstand how that's supposed to work. If the implication is that the OS is supposed to have paired it .. if it's a serial port already at the point it reaches the browser that's fine, but what if you want to do it fully on the browser? How do permissions work in that case?

Dan: agree. It's obviously using the serial api

Sangwhan: but what happens before that

Dan: what's the full flow

Sangwhan: it's valid to answer that it's supposed to be paired at the OS level. But then I have questions about ChromeOS.. (homework for myself)

Dan: drafted my comment.. I'm personally not against this API. I'll leave it and Sangwhan you can follow up with anything additional

We've reviewed the Web Bluetooth API posotively.

We've also reviewed the web serial API - for which we recognized the use case but also we expressed concerns about multi-stakeholder support.

Speaking personally, I'm a big supporter of these APIs. I've personally demonstrated Web Bluetooth on stage at developer events. I fully get it. However, as TAG I have to acknolwedge that the development of these capabilities has not brought other implementers along.

Putting aside the multi-stakeholder considerations, we're not clear on some aspects of the user flow and permission model. The explainer could benefit from spelling out how a device gets connected, how the permissions are requested, etc... ?

Sangwhan to write closing comment as satisfied with concerns

Dan: considering this is building on top of web serial, which we did not have negative feedback on, and that they have documented use cases and user needs - specifically in the education space - it feels like this should get a "satisified with concerns" from us - the concerns being the multi-stakeholder support which is really the underlying web serial and web bluetooth.

Sangwhan: OK with that. No concerns with the design.

Dan: will set to proposed closing and we can close at the plenary.