On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams <[email protected]> wrote:
> On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: > > > OK, but why not put all of this into the headers anyways? > > > > Well that is what I suggested in my Content-Signature work and that is > > exactly how my code works today. But folk proposed introducing the > > signature in the HTTP content segment and that forced me to think about > > which approach is better. > > Your approach looks like a Transfer-Encoding to me. If that's what it > looks like, and that's what it walks like, [and that's what we want,] > then that's what it should be. Umm, I designed the Chunked transfer encoding. A TE gives the length of blobs. This is not a TE. > > > I think I can make a good architectural argument for the JSON Container > > approach and besides which it is really useful at the file system level. > > You want the contents of the object to include the signature?? > No, I want the option of doing drag and drop on the file plus metadata blob in a fully interoperable fashion. So the contents are still the contents. But they are prefixed by the metadata. > I mean, I've wanted filesystems to expose some internal metadata (e.g., > a Merkle hash tree root hash for a file's content, with those parameters > needed to reconstruct the same hash from just the contents, namely, the > shape of the tree and the size of each non-tail block of contents). But > making this part of the contents instead of the metadata strikes me as > rather problematic. It isn't making it part of the contents. Metadata is still metadata. Trying to get the file system to support additional semantics is a losing proposition. And even if they are supported they won't be standard across all the platforms. > > > Separating out protocol data from content-metadata is long overdue. > > Maybe, but I do want POSIX to continue not commingling contents and > metadata. I want POSIX to curl up in the corner and die. Co-mingling the contents and metadata are an inevitable consequence of considering files to just be a stream of bits. inside the container is the only place that metadata can go. UNIX has had horrid kludges for putting metadata into the content since the start. Thats what magic numbers are. > Sort of. That might be where we eventually do the work. But the > > requirements would be ACME in the first instance and the constraints from > > JSON. I would see JOSE as being something we just plop in and should work > > (or else they have some splainin' to do. > > I meant: why not use whatever JOSE delivered? > Base64 encoding the content so as to be able to work out the boundaries. Blech.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
