This includes replacing "client" and "server" in some but not all other parts of the document. I think we should keep those two words specifically when specifying things pertaining to the QUIC protocol as it uses those words explicitly, and keep with the three I've used here.
Oh,, and this takes a first pass look at encryption - which I think we're going to keep getting into. Current thinking is to expect that key exchange should be decoupled from the protocol, but the protocol has to support enough metadata for subscribers (or authorised relays) to be to work out how to decrypt and hand it out of band. This would make many of the existing and future systems both in DRM and those used in real-time media feasible.
Closing this as not to do just yet - ontology may go into a separate architecture document. I'll leave the branch in tact for now so if we come back to it after other changes (and publishing -04) it's available.
This includes replacing "client" and "server" in some but not all other parts of the document. I think we should keep those two words specifically when specifying things pertaining to the QUIC protocol as it uses those words explicitly, and keep with the three I've used here.
Oh,, and this takes a first pass look at encryption - which I think we're going to keep getting into. Current thinking is to expect that key exchange should be decoupled from the protocol, but the protocol has to support enough metadata for subscribers (or authorised relays) to be to work out how to decrypt and hand it out of band. This would make many of the existing and future systems both in DRM and those used in real-time media feasible.