Meeting minutes
<J_Hudson> What’s Zoom passcode?
Vlad: re: the title, "incremental" will replace "progressive"
Vlad: If we will be creative about the title, then we can try to come up with something which has a pronouncable acronym
Garret: I tried to lay out section headings
Garret: I didn't do it for range requests though
Garret: So i'll leave range request stuff empty until myles can get his act together
Garret: The structure of this is close to the design doc which I sent out. I made some chagnes, but it's more or less the same. Section 4 isn't filled in, but this will cover backwards compatibility design doc - how do you use this on your page, and how does the client figure out which variant to talk to the server
Garret: Complete description of patch base, the range base, and that will paint a complete picture.
Garret: Beyond the headings, I filled out the data type section. This will build up the foundation upon which the rest of the spec will rest. All of the message formats and teh data types that will be going back and forth. None of this should be new - its' all in the previous design doc, but I've been rewriting them to be more formal.
Garret: The previous version of the doc wasn't at a level sufficient to be a spec. It's a WIP.
Garret: We're gonna use CBOR as the serialization format.
Garret: We have a few basic types: sparse bit set. I rewrote this section to be more formal with a recursion relationship. And an example.
Garret: I'm most interested in having people review this section.
myles: The audience is browser implementors, not font creators, right?
Garret: yes.
Garret: The other main piece is objects: key/value data structures encoded with a map in CBOR. Keys will be numeric IDs.
Garret: Key/values with optional fields allows these to be extended in the future - backwards compatibility
Garret: Also request/response message types, and the fields, their IDs, and the types of the data in those fields. This matches the previous design document.
Garret: The next part will be describing the behaviors of the request / responses, errors, etc.
Garret: One section I'll add will describe what the server does, and some basic descriptions of the algorithms.
Garret: Another missing section: the client algorithm (and the server algorithm)
Garret: I'm going to continue to work on it throughout the coming weeks.
myles: opt-in mechanism in CSS will be in CSS document, not this one, right?
Garret: Yes, though we will want an example in this document.
myles: ok
myles: let's go ahead and open an issue in CSS to get the new keyword added
Vlad: we'll be linking to CSS
myles: i'll do it
Vlad: if `supports` is still in a CSS draft, then we can add to it
myles: we need some overview that describes the relationship between teh two approaches
Garret: Some of that is in section 4, but we can put non-normative stuff in section 1
Garret: I don't have a lot of experience writing specs, so I would welcome feedback
Garret: Earlier rather than later, please
Vlad: absolutely
Housekeeping
3 action items are open
Vlad: one is on myles, one is on Garret. At least one is probably able to be closed?
Vlad: We can close 227 and 227
Garret: we can close 229 too
CLOSE ACTION-227
<trackbot> Closed ACTION-227.
CLOSE ACTION-228
<trackbot> Closed ACTION-228.
CLOSE ACTION-229
<trackbot> Closed ACTION-229.
Introductions
Mark Ayasse: I'm at Monotype, in discussions about how to handle fonts on the web
<general discussion about IRC>
Vlad: It's important to mark who is present when a formal decision is made
Vlad: Any other topics?