Consider making PATCH optional and/or removing/deferring it

[mmccool]

Support for PATCH is complicated, and is really an "optimization" since updates can be done using entire TDS, so maybe we should apply the KISS principle and take it out. Really two issues:

1. Complex, so implementers may not want to support it. We can deal with that just by making support for it optional.
2. Hard to fully specify for JSON-LD. Ideally we would refer to a separate fully-tested and supported specification for how to do this. If one exists. If one does not, then we have to do a lot of work to fully specify this, maybe collaborate with the JSON-LD group, etc. If we can't get this all done in time to meet our deadlines we may be forced to remove it.

Note we also need two implementations (not completely required for optional features, but still highly recommended).

[mmccool]

This may or may not be a problem if we stick to the JSON level; let's discuss.

[relu91]

By the way, there is this RFC about JSON "patching": https://tools.ietf.org/html/rfc7396. I don't know if it was already discussed, but I think it is a great start.

[farshidtz]

By the way, there is this RFC about JSON "patching": https://tools.ietf.org/html/rfc7396. I don't know if it was already discussed, but I think it is a great start.

I didn't know about this RFC, but that's exactly how I expected a server would process the PATCH request body. We could refer to this specification not only for the registration PATCH, but also for notification diffs suggested in #87 (comment).

The application/merge-patch+json content type can be recommended instead for partial TDs that aren't JSON-LD, though application/td+json isn't mandatory per current spec.

[mmccool]

We have decided to include PATCH, basing it on RFC7396, which is relatively simple and for which there are good libraries available, so implementation is straightforward. It is, however, a mandatory feature (to save bandwidth for IoT devices). It may however interact with non-JSON (string only) representations of TDs (e.g. encrypted), so we may have to follow up when we discuss those.