headers
Tanu Mutreja | 6 Jul 16:51
Picon

Suggestion : New Content-Disposition parameters...


Hi Everybody,

Further to the document posted at 
http://xml.resource.org/public/rfc/html/rfc2183.html , I would like to 
suggest adding few more content-disposition parameters. I would be 
grateful if you could please spend some time on reading this mail and 
provide your valuable inputs.

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

Since the very basic nature of email involves extremely wide 
transmission of content, maintaining information like the above becomes 
quite useful. It can help retaining & tracking down basic history and 
information of the original content flowing throughout the email 
messages. Even though it's just a recommendation and the recipient is 
free to comply or not to comply, it can definitely help the sender 
guarding content to some extent.

To add further, my feeling behind the suggestion is that 
"content-disposition" header is intended to provide the sender a way to 
make his / her recommendations to the recipient about the MIME entities. 
Some of the MIME entities carry a set of properties like above.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Keith Moore | 6 Jul 21:11
Picon

Re: Suggestion : New Content-Disposition parameters...


I have two kinds of reservations about this:

1. indicating any copyright information in the headers of a body part
2. using content-disposition for this purpose

Copyright is by itself a problematic issue.  Many  people (including
myself) believing that traditional notions of copyright are obsolete and
harmful when applied to the networked world.

It's not immediately clear how the information would be used  by the
recipient.  In countries that have signed the Berne convention, 
essentially everything is copyrighted anyway.  And yet the very actions
of transmitting a message over email, reading the message from a message
store using POP or IMAP, and using attachments (e.g. providing a copy of
"just the attachment" in a file where it can be used by a  helper
application) requires making several copies of the message.  
Furthermore, to be effective any kind of limitation on the use of the
attachment would need to be communicated to any helper application (so
that, for instance, "save" or "print" functions could be disabled or
limited).  In this context it seems clear that (if the sender has the
right to do so) some permission to copy is being granted by the
sender to the recipient and to various intermediaries, or (if the
sender does not have that right) that the sender is violating one or
more rights held by the content owner.

Also, copyright laws are particular about what kinds of marks are 
suitable for legally serving as copyright notice, and it's not clear 
that a new content-disposition field, or a new body-part header field, 
would meet the requirements of such laws - particularly when the notice
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 7 Jul 01:03
Picon

Re: Suggestion : New Content-Disposition parameters...


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

I agree with Keith's remarks posted to ietf-822.

In addition, I would point out that the first three items are already handled
within the content for some media types (e.g. application/pdf). In such cases,
inclusion of the same type of information outside of the content can lead to
one of the following problems (or a combination of the two):

1. the information is redundant, and therefore wastes some bandwidth
2. the information does not match that within the content, leading to
   ambiguity

In cases where the content has no such provision, such information could be
provided textually by wrapping it in a multipart/mixed wrapper with the
actual content.  The information could even be given a different disposition
than the content, e.g. it could be marked for inline presentation, while the
content could be marked as "attachment".  Unfortunately, some UAs don't
handle nested MIME parts well more than a decade after MIME's introduction,
but that's another matter.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Moore | 7 Jul 05:44
Picon

Re: Suggestion : New Content-Disposition parameters...


> In addition, I would point out that the first three items are already 
> handled
> within the content for some media types (e.g. application/pdf). In 
> such cases,
> inclusion of the same type of information outside of the content can 
> lead to
> one of the following problems (or a combination of the two):
>
> 1. the information is redundant, and therefore wastes some bandwidth
> 2. the information does not match that within the content, leading to
>    ambiguity

this brings up (for me) the question of where the information about 
copyright is obtained in the first place.  body part fields are 
supplied by the sender (or his UA) but the sender might not be the 
copyright holder of the attachment.  should the recipient trust the 
sender's assertion about such rights?  the sender could easily get it 
wrong.
Permalink | Reply | 0 comments |
headers
Graham Klyne | 7 Jul 10:14

Re: Suggestion : New Content-Disposition parameters...


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).

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.

At this stage, you seem to be suggesting a solution without being clear how 
the information would be used -- is intended to be displayed to a message 
recipient, or consumed by a receiving application, or something else?  A 
clear statement of this requirement would, I think, make it easier to 
suggest appropriate ways of conveying the information.  Also:  how
(Continue reading)

Permalink | Reply | 11 comments |
headers
Bruce Lilly | 15 Jul 16:15
Picon

Mandatory From field, anonymity, and hacks


RFC 2822 has relaxed some requirements which existed in RFC 822 w.r.t. mandatory
header fields (822 required at least one of To, Cc, Bcc; 2822 has no such
requirement).  However, both 822 and 2822 require a From header field.

Transport (IMAP, POP3, NNTP, SMTP, etc.) of messages does not make use of the
>From field.  The From field in an original message is not used in preparation
of MDNs (Disposition-Notification-To is used) or DSNs (envelope return address
is used).

In some cases, a message author desires some degree of anonymity.  The
requirement for a From field has led to the use of some hacks in order to
comply with the letter of RFC 2822 and its predecessors, while providing some
degree of anonymity and rendering the From field unusable for manual replies.
For example, RFC 3261 section 23.4.3 and RFC 3323 section 4.1.1.3 recommend
use of the reserved DNS ".invalid" domain (RFC 2606) to provide some degree
of anonymity.  There are some Internet drafts which do likewise.  I believe
such use goes somewhat beyond the intent of RFC 2606 in reserving names for
test and example purposes.

Making the From header field optional would eliminate the need for such hacks
by persons who desire the degree of anonymity that such hacks provide; those
persons could simply avoid including a From field at all, rather than
including a hacked bogus address in a From field.

The same considerations apply in the case of the Resent-From field.

Of course, in the absence of a From field, treatment of manual replies may
need to be worded slightly differently.  A Reply-To field, if present, would
be used whether or not a From field were present. It may also be worth
(Continue reading)

Permalink | Reply | 611 comments |
headers
ned+ietf-822 | 16 Jul 21:13

Re: Suggestion : New Content-Disposition parameters...


> 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
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bruce Lilly | 17 Jul 21:28
Picon

Has IANA gone mad?


Sent to ietf-822 and ietf-msgtrk mailing lists, cc to iana <at> iana.og, responses
default to ietf-822

Yesterday, "message/tracking-status" appeared in the IANA registry for MIME
message media types (http://www.iana.org/assignments/media-types/message/).
It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference document -- of
course there is no such document.  The closest existing document is a draft
dated March 2003, more than a year old ("Internet drafts are valid for six
months").

Why on Earth did this suddenly appear yesterday?

The ietf-msgtrk mailing list appears to be dormant; in the last three months
the only message to appear on that mailing list's archive are spam messages
(http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html).  There are fewer
than a dozen message in the mailing list archive in the past year, spam
included.

What's going on?!?
Permalink | Reply | 1 comment |
headers
Bruce Lilly | 17 Jul 21:38
Picon

Re: Suggestion : New Content-Disposition parameters...


ned+ietf-822 <at> mrochek.com wrote:

> 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. 

The above and Keith's comments w.r.t. copyright notwithstanding, what about
some indication by the author to indicate a preference against long-term
archiving of the media content?   That is distinct from copyright and from
the inherent ephemeral copying necessary for transport, but is meant to
address long-term archiving.  There is now in use an undocumented, unofficial
header field "Archive" used in Usenet messages for such an indication; might
that be suitable as a Content-Disposition parameter instead?
Permalink | Reply | 9 comments |
headers
Bruce Lilly | 17 Jul 21:41
Picon

Re: Mandatory From field, anonymity, and hacks


One implication that I missed is w.r.t. the MIME media type message/rfc822,
which currently requires one of From, Subject, or Date fields in the media
header.  That might need to be reduced to one of Subject or Date.
Permalink | Reply | 0 comments |

Gmane