Meeting minutes
Myles: I've got a PR that merges the two specs. For the most part it was just a matter of moving the content of the range request doc in and adjusting headers. There's a couple of changes that I made beyond that.
Myles: the method negotiation section was present in both docuemnts. I decided to keep just the one from range request because it was more complete and that's where ongoing discussion was.
Myles: if anyone doesn't like the decisions we should discuss.
Myles: in the previous call Chris said the two documents are organized differently and he prefered the top down approach. I didn't do any re-organization to match that structure.
Myles: if he is correct and we want to be consistent between the two parts, then there will be more edits.
<myles> Garret: I agree. Splitting this merge into 2 pieces: first a simple one, then a more in-depth one, is a good idea.
Vlad: agreed as well.
Myles: Garret are you ok with the deletions.
<myles> Garret: I want to do another pass to make sure, but probably yes.
Vlad: we should all take a close look and make comments.
Garret: planning on reviewing today.
Garret: I won't be able to make next weeks call.
Myles: so cancel next call?
Vlad: if we don't have anything to discuss thats fine.
Myles: one last thing I kept the patch subset section first.
Garret: I noticed the patch subset description was quite short, once you merge I can expand that.
Myles: sounds goodl.
Vlad: next topic, remaining open issues.
Garret: 1. concern about using a query parameter. In the first incremental transfer request you make, we embed the patch subset request in a query parameter. If the server understands that, it will respond with patch subset, otherwise it will just reply with the response. This is a query parameter so that this works nicely with COORS. The first request can't be a POST otherwise there can't be range-request fallback.
Garret: The issue is that there's a concern that the server should have authority over their own URLs. Maybe we can solve this with client hints, or using the URI template <missed>
Garret: I don't think client hints are going to work, because that will require a round-trip for the browser to get back info on which ..... Client hints are a mechanism for the client to tell the server what it supports.
Garret: I'm not too familiar with the URI template stuff, so I plan on reading it
Garret: I'm also not sure if this is a big problem - the server explicitly determines its own URL
Vlad: Thanks for explaining. It was cryptic to me.
Garret: I'll research URI template first, and after that I'll write up a response with much of what I said here.
Garret: 2. Some performance concerns with range request. The first connection gets cut off after you get everything other than the glyf table. THis is probably one for myles to read through.
<Garret> Myles: my immediate thoughts, you don't need to kill the connection. They way we load incremental PDF uses the same approach. We have one connection loading the whole document while another in parallel does incremental loading.
Garret: That makes sense. myles, can you respond to this issue?
myles: ok.
Vlad: for remaining issues could Myles and Garret review the patch subset and range request tagged issues and see if any action can be taken to move them to a closed state
Vlad: if edits are required ideally a link to the PR making the changes.
Myles: I'll make a pass.
Garret: me too
Vlad: we'll be able to close #48 the merge issue soon.
Myles: I'll wait to close until the PR is merge.d
Vlad: next topic, when the FPWD for range request was published the patent exclusion opportunity opened again. So just a reminder that is public now and starts the 150 day window so remind your representatives to act on it if needed.
Vlad: next item as last minute addition. I was contacted by atypi. They are starting to organize for this year.
Vlad: we did a preso last year. I think we can come up with something meaningful this year as well.
Vlad: another opportunity is to do a video demo for W3C at tpac.
John: there's an online type tech that's being organized a few times a year. One thought I've had it's still at the very complicated stage in terms of my understanding of it. So we need to think about how to succinctly explain it to non-tech people. For example foundries. There will be questions about licensing. So being able to explain to foundries to help them make those decisions
Myles: this group should probably not make decisions about licensing.
John: agreed, I'd just like to get them the information they need to make decisions.
Myles: make sense.
Vlad: help foundries understand what typical usage scenarios are like.
Vlad: it's not always transparent and can cause confusion.
Vlad: other venues?
Jason: there's always more web development focused conferences. Where there will probably be interest in it.
Vlad: probably a bit early since we haven't fully nailed down the mechanism for opting in. Once we have a agreement on how the tech is deployed.
Vlad: our group has been chartered quite some time ago, the original term ends this september. So probably in June/July we'll need to think about a charter extension. We'd need to provide a reasonably complete summary of what we've done and how much additional time is need. ie. conformance tests and finishing up the spec.
Vlad: will need to be approved by charter committee. They will need to be made aware of what we're doing and the importance.
Vlad: that's it for the agenda items.
Vlad: any other topics?