Stefan Matsson

Pardon the late reply! I've been swamped the last couple of weeks. Naming is truly hard :D I think most of these are OK and just to make it more...

> The specific metadata keys documented herein are reserved for the > respective use and MUST NOT be used for other purposes. Note really a fan of this part at...

@nigoroll To be the devil's advocate: Why would we need to reserve metadata keys to begin with? The 1.0 version of protocol has been around since 2015 and haven't included...

@nigoroll I'm only concerned with the breaking changes and that the protocol will be ambiguous between implementations and when they were implemented (as the spec changed). As I said earlier...

Do we need to consider the Content-Encoding changing between requests? E.g. the file is created with `Content-Encoding: gzip` but the client then decides to not include it (and not encoding...

This is a complex issue and I need some time to think things through. tusdotnet does the same thing as tusd (https://github.com/tusdotnet/tusdotnet/blob/master/Source/tusdotnet/TusProtocolHandlerIntentBased.cs#L96) as this is the way I interpret the...

> > I don't think it's clear from the current spec that the version is semver. > > That's a good point to improve if that's the case. The spec...

> > Given this we should just be able to increment minor/patch when new things are added. Maybe start with 1.1.x and update tusd, tusdotnet, ts-js-client etc? > > Yes,...

> I really like how the OpenAPI specification describes version handling: https://swagger.io/specification/#versions It very elaborate and detailed, making it easy for implementations to follow the specification. We could use that...

@Acconut > The server can always add additional metadata to the upload that the client can fetch using a HEAD request. Using that workaround that is already possible. Should we...