CfC - publication of Web MIDI API as First Public WD (Was: MIDI spec updates, as per telecon)

Dear all,

At the teleconference yesterday, we discussed the Web MIDI API spec, and agreed we'd like to publish as First Public Working Draft next week if Chris found the time to make a few edits - which, as you can see in his e-mail he did.

Publishing at this point will allow us to publicise the work at TPAC, and get more feedback from the public on a spec which is already quite mature. Kudos to the editors.

If there is no objection by Tuesday morning (Boston time) we will assume consensus and will move forward with publication.

Thierry will lead the process for publication, as usual. 
Thierry, since this is a FPWD, can you get the green light for the "webmidi" shortname?

Thank you.
Olivier

On 18 Oct 2012, at 00:42, Chris Wilson <cwilso@google.com> wrote:

> I have updated the Web MIDI API specification, as per the discussion in today's teleconference, with one addition.
> 
> The changeset is here: https://dvcs.w3.org/hg/audio/rev/f4727ce84474.
> 
> The updated spec is here: https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html.
> 
> I made the following edits:
> 	• I expanded the overview section, making it clear that this API is not intended to cover semantic controls through MIDI (i.e. a solution to the web of things problem), and also that this API is not concerned with Standard MIDI Files or General MIDI - that is, that it is concerned with input and output, not "playback" per se.
> 	• I greatly expanded the introduction section to provide a more table-of-contents style overview of the API, and also to describe in more detail how the API is intended to function.
> 	• I essentially rewrote the Security and Privacy considerations section to describe the fingerprinting and access concerns in more detail, and also (per conversation in telecon) to explicitly leave the model open.  These three edits should resolve bug 19187.
> 	• I changed the sendMessage() method back to my suggested three-parameter form, and explicitly excluded sysex from sendMessage().  I expect further discussion on this point, but for our FPWD, I wanted to have it this way as I was brainstorming the security and privacy constraints, and I think it may be possible to use sysex as the "needs user permission" switch - that is, to require user permission ONLY in order to send/receive sysex.  I'm not positive this will be enough, but it will be easier to change it back than it would be to break variadic usage later.  ref: Bug 18764.
> 	• I explicitly made timestamps in MIDIMessage allowed to be set to zero, with the semantic of "send now", as per Bug 18760.
> 	• I added IDs to several elements in order to provide forward links, and I expanded some of the IDL constructs to better show the descriptions of individual method parameters or members.  (no substantive changes.)
> -Chris