> our metadata spec is not based on HTTP. Our metadata spec does not, in > fact, have anything to do with the HTTP spec whatsoever. Oh stop being so damned short sighted. The HTTP spec has good ideas related to metadata, Content-Encoding is one of them. Just because we arent the W3C doesn't mean we can't use their ideas.
> I see no benefit to adding a ContentEncoding field which is not equally > satisfied by adding a ContentDecoding field. Additionally, a > ContentDecoding field allows for clients to optionally support it rather > than being required to. What?! "Encoding" .. as in "Encoded in". > > Viewing is not the only thing contingent upon the associated MIME type of > a file being correct. Some clients might want to automatically guess a > reasonable filename and add an appropriate extension. This is a reasonable > feature even for command line clients and certainly a nice thing to have > for a Gnutella-style downloader client that lacks viewing capabilities but > allows for lots of simultaneous downloads. > No, thats not what the mime type is for. Read the mime RFC please. > Generally, my complaint is that an additional required field is being > added in order to support behaviour that should clearly be optional and > doesn't make sense for all reasonable clients. I'd prefer to have the > required fields be constrained to those that are necessary for any > reasonable client. Additionally, I find no relevance in what HTTP > considers to be standard headers, although it is a good source of ideas > for new optional headers that add value. <sigh> -------------- 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/20010503/ed70fedf/attachment.pgp>
