Meeting minutes
<skef> zoom needs me to update. That might take me a bit.
IFT spec review
scribenick Garret
scribenick! Garret
Latest version of the spec is at https://
Discuss proposed ID encoding switch to base32hex: see PR169 and related issue #167
Skef: motivations, there's an ID which identifies patches (of any style).
Skef: there's a bunch of considerations when encoding into the URL.
Skef: sometimes this ID is just a number, needs to be encoded in the URL. Previously we just used hex, on byte boundaries and no padding. Not very compact.
Skef: if the goal is to spread files out over directories you only get 16, typically you provide some charracters from the ID (either leading or trailing) as directory names.
Skef: other kind of ID is some string that the encoder has provided. The id there is there may be a set of parameters that you want to encode to allow dynamic generation server side.
Skef: things were numeric id hex encoded, otherwise string is inserted in a url safe way.
Skef: after discussing there's two considerations, one is being URL safe and not having to play games to get it into the URL, and then there's the file system. Some windows file systems are case insensitive. So if you're using base64 you could get collisions since the encoded has different meanings for upper/lower case.
Skef: so we gravitated to two encodings base32hex for file systems 0-9, A-V no lower cases, and base 64 url. Both need padding, padding only needed though when the encoded needs to be reversed. For base32 it's not important so no padding, for base 64 we will keep the padding. base64url will work in all filesystems except for case insenstive file
systems.
Skef: there's some additional issues that came up as I was reviewing the PR, made if a draft for now so we can discuss them.
Skef: base64 padding is still an equal (=), there's still two char left.
Garret: we could consider switching to a different padding character like "." which was not used because not good in fs. Or just leave it up to the enocder to sort out.
Skef: custom ID patches if you want those spread out over the file system. Then it will be up to the encoder to put something unique in the tail.
Garret: agreed could be a note.
Garret: for "I'm not sure the distinction between converting to UTF-8 for base32hex and encoding the raw string for base64url is right. (Not sure it's wrong either, we should talk about it.)" I think we should just remove the note that raw id strings are utf8 encoded and just treat them as binary data for both encodings.
Skef: feel free to add a commit to my PR with suggestions.
Vlad: has this fs encoding problem come up in other specs/cases?
Garret: base spec does address this in some of it's encodings.
Skef: other use cases often do things like use md5 checksums and use leading/trailing digits to spread things out.
Skef: I was pulling character from the top of the string, Garret switched it to the end.
Skef: there's a goal these should be portable. Ideally you should be able to copy those where you want and use them.
Skef: especially with integer ids that are sequential.
Garret: next PR to review #163 handling errors.
Garret: is there any remaining concerns with the current wording?
Skef: have some remaining abstract concerns but I don't think that should hold this up, so good to merge.
Garret: sounds good, we can definitely continue to iterate on the text in the future.
Garret: next up I'm working on the privacy and security sections.
Skef: the encoder section has a couple of things needed that aren't captured in TODOs.
Garret: yeah, I have a list I'm keeping separately but I'll go update that section to add the TODOs so we don't lose track.
Garret: Topic: reviewing open issues.
Garret: issue #101 shared brotli expierd.
Garret: we can work around around this by copying the paragraph we need from the brotli spec. I don't expect this to change going forward as an implementation of this functionality is already part of the public brotli repo.
Skef: related there's the issue of brotli being available in the streaming compression apil.
Garret: don't need to track that here, but I can follow up with them.
Garret: next issue #103 a-la-carte IFT.
Skef: still think this is relevant. Implementations likely want this information. Especially with features. Would be good to have an API for this.
Garret: I think it likely makes sense to have this as an extension to the javascript font loading api. Once we have a stable version of the spec rewite we could start talking to that wg.
Garret: next #109.
Skef: I think this is no longer relevant.
Garret: agreed, can likely close.
Vlad: we should check in with Yoav first.
Garret: sounds goodl.
Garret: #127 QUERY support. I think we can close this.
Skef: it might still be relevant due to url size limits.
Garret: so I think this should just be something the encoder needs to be aware of and deal with. So I don't think we need to address that in the spec by having QUERY.
Garret: we should make a note in the spec about the URL length limits.
Garret: we have agreement this issue should be closed.
Garret: 160 and 167 are both new issues and still relevant.
Garret: leaving open
Vlad: lastly, we have the IFTB draft PR which is open.
Garret: we will want to close that eventually, but I've found it useful to have the PR around to pull text from it for the spec rewrite. We'll leave open for now.
Vlad: what would be the good time for the next call?
Garret: probably don't need another in 2 weeks, let's tentatively say Jun 4th for the next one.
(28th is the memorial day weekend in US)