At 20:21 06/07/04 +0530, Tanu Mutreja wrote:
>I feel that few more parameters should / could also be added to the list
>of content-disposition parameters. To be more precise, following
>parameters related to the origin of a file should also be added i.e.
>
>1. Source of the file creation
>2. Author of the file
>3. A parameter to represent if the material is copyrighted or not?
>4. Version of the file
Notwithstanding the problematic issues noted elsewhere, I think it's also
important to consider that Content-disposition is *not* a catch-all bucket
for arbitrary message-content metadata (as Keith has also noted).
Quite right. Content disposition paramaters are supposed to carry generally
meaningful information that may be needed to act on the associated disposition.
So we have filename, creation date, and modification date parameters, which are
all useful when putting message content in a file, which is what the
attachment disposition often ends up doing.
Creator/author identity only kinda sorta falls into this category; IMO
version and copyright information miss it by a mile. Additionally,
I have difficulty imagining a useful matchup between what filesystems store
about file creators/authors and what you'd put in such a parameter.
I think that alternative mechanisms that might be considered include:
- new header fields
- packaging the message with something like multipart/related and
additional content containing a widely used metadata format (e.g. RDF)
- linking the metadata to the content with something like a signature
structure (e.g. along the lines of http://www.w3.org/TR/xmldsig-p3p-profile/)
- incorporation into a Content-features header (RFC2912); though this
might be regarded as stretching this beyond its original intended purpose
of conveying *media* features.
I don't think it is all that much of a stretch to call it a media feature.
As such, I'd say RFC 2912 would be the way to go for this, assuming it
makes sense at all (I remain to be convinced).
Ned