> > The client has to decrypt the metadata and find the content-type > anyway. That's what clients do, they fetch the file, decrypt it, find the > content-type, and then deal with the file appropriately based on what type > of file it is. If the metadata is in an unreadable format, it won't be > able to determine the content type and so won't be able to do anything > with the file except for display the undecipherable metadata to the user > and save the data to disk. So if the file is a redirect formatted in XML > then the redirect won't work. But in your system it won't work either. You > just specify that redirects, etc. have to be FNP. No. You're really in some sort of mental block here. My scheme only specifies *when* FNP is used. Content-type is a convention, its not a hard written law. I don't see why you have to have content-type to determine anything. Its useful when you're dealing with real data, but its optional.
> > I will also specify that if you have a special file, then it must be > formatted in FNP in order for FNP clients to read it. But it can also be > formated in XML in order for XML clients to read it. You're missing the point. The client has to do a lot of work to determine which form its in in your format. > I think a better solution would be explicitly state what kind of metadata > was in the metadadata field. How? You can't state what type of metadata is in the metadata field without specifying a metadata form to store that representation? Thats a circular nonsensical requirement. > Metadata-format==0 (0 for FNP, 1 for XML, etc..) is faster. > I'd prefer something more explicit such as Metadata-format=="FNP" which > shouldn't take much more time and would be much more explicit. But your specifying that that be stored along with the data, which is a nice little security hole. Now people know what kind of metadata is being used, which if it isn't common, reveals much about it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000819/3f966adc/attachment.pgp>
