> It looks to me like another incentive to use multipart messages (as if
> the parallelism and the mixmasterliness of it weren't enough).
> 
> Has there actually been a concrete proposal on how to do multipart?  I'd
> be tempted to work on the code, if I knew what the data was supposed to
> look like.

I would put the part information in the metadata and other than that have
them look like normal files. So what we really need to implement next is
the metadata, for which we have a concrete proposal. Here is my version of
the proposal, mixing the truly agreed upon things with my ideas on the
subject.

There is a field containing public, plaintext metadata, in the dotted
field format.

PublicMetadata.Expires=10/26/2002
PublicMetadata.HeaderLength=1002
PublicMetadata.Encryption=RC4

The HeaderLength field refers to the length of the header in the trailing
field.

The trailing field is formatted just like a message, with fields and a
trailing field. It is encrypted with the Encryption method. The first
HeaderLength bytes are the fields and the part after that is the trailing
field.

Inside the trailing field, we currently (but not necessarily
permanently) allow only PrivateMetadata dotted fields.

PrivateMetadata.PartNumber=1
PrivateMetadata.NumberOfParts=10
PrivateMetadata.Author=Brandon
PrivateMetadata.MIMEType=text/plain
Data
blahblahblah

Each multipart item should probably contain a list of keys for other
parts.



_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to