headers
kmark | 12 Mar 1996 22:38

RFC 1806 vs. Application content-type "NAME" parameter


In the MIME RFC 1521, section 7.4.1 states the following:

  RFC 1341 also defined the use of a "NAME" parameter which gave a 
  suggested file name to be used if the data were to be written to a
  file.  This has been deprecated in anticipation of a separate
  Content-Disposition header field, to be defined in a subsequent RFC.

The subsequent RFC that is referred to is 1806, which is still categorized as 
"experimental".

Since RFC 1521 discourages the use of the old "NAME" parameter, my question 
is this:  when trying to communicate file name information between old and
new MIME mailers, is it recommended to upgrade the older application to 
employ the "experimental" RFC 1806 or to "downgrade" the new application to 
RFC 1341?  Has RFC 1806 achieved widespread popularity among MIME mailers?

Thanks in advance,

Ken Mark
KMark <at> zoomit.com
ZOOMIT Corporation
Permalink | Reply | 4 comments |
headers
Rens Troost | 12 Mar 1996 23:20

Re: RFC 1806 vs. Application content-type "NAME" parameter

> 
> Since RFC 1521 discourages the use of the old "NAME" parameter, my question 
> is this:  when trying to communicate file name information between old and
> new MIME mailers, is it recommended to upgrade the older application to 
> employ the "experimental" RFC 1806 or to "downgrade" the new application to 
> RFC 1341?  Has RFC 1806 achieved widespread popularity among MIME mailers?
> 

It gets worse. some mailers use 'Content-Description' for the
filename.

By and large, 1806 is in use. Best thing to do is use both methods,
and prefer C-D on reciept.

-Rens
Permalink | Reply | 3 comments |
headers
Jim Conklin | 13 Mar 1996 11:52

re:RFC 1806 vs. Application content-type "name" parameter

  I'm forwarding this to the list for kmark <at> zoomit.com.  //Jim

>
>In the MIME RFC 1521, section 7.4.1 states the following:
>
>  RFC 1341 also defined the use of a "NAME" parameter which gave a
>  suggested file name to be used if the data were to be written to a
>  file.  This has been deprecated in anticipation of a separate
>  Content-Disposition header field, to be defined in a subsequent RFC.
>
>The subsequent RFC that is referred to is 1806, which is still categorized as
>"experimental".
>
>RFC 1521 discourages the use of the old "NAME" parameter.  My question is
>this:  when trying to communicate file name information between old and new
>MIME mailers, is it recommended to upgrade the older application to employ the
>"experimental" RFC 1806 or to "downgrade" the new application to RFC 1341?
>
>
>Thanks in advance,
>
>Ken Mark
>KMark <at> zoomit.com
>ZOOMIT Corporation
>
>
Permalink | Reply | 0 comments |
headers
hansen@pegasus.att.com | 13 Mar 1996 21:29

Re: RFC 1806 vs. Application content-type "NAME" parameter

<< Since RFC 1521 discourages the use of the old "NAME" parameter, my
<< question is this:  when trying to communicate file name information
<< between old and new MIME mailers, is it recommended to upgrade the older
<< application to employ the "experimental" RFC 1806 or to "downgrade" the
<< new application to RFC 1341?  Has RFC 1806 achieved widespread popularity
<< among MIME mailers?

< It gets worse. some mailers use 'Content-Description' for the filename.

I haven't seen this, thankfully.

< By and large, 1806 is in use. Best thing to do is use both methods, and
< prefer C-D on reciept.

This is the only workable solution we've come up with.

					Tony Hansen
			  hansen <at> pegasus.att.com, tony <at> attmail.com
		    http://ourworld.compuserve.com/homepages/Tony_Hansen
From jpalme <at> dsv.su.se Thu Mar 14 10:01:32 1996
Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by list.cren.net
(8.6.12/8.6.12) with ESMTP id KAA23149 for <ietf-822 <at> list.cren.net>; Thu, 14 Mar 1996 10:01:31 -0500
Received: (from jpalme <at> localhost)
	by ester.dsv.su.se (8.7.1/8.7.1)
	id QAA08669;
	Thu, 14 Mar 1996 16:01:19 +0100 (MET)
Date: Thu, 14 Mar 1996 16:01:18 +0100 (MET)
From: Jacob Palme <jpalme <at> dsv.su.se>
To: ietf-822 <at> list.cren.net
cc: Lars Enderin <enderin <at> dsv.su.se>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Palme DSV-SU/KTH | 14 Mar 1996 01:00
Picon
Picon

Re: RFC 1806 vs. Application content-type "NAME" parameter

If PINE receives a message with a "NAME=" in the header, PINE will
treat the whole message as an attachment, which must be viewed
with the special tools in PINE for viewing attachments. Some
mailers put "NAME=" on all messages they send, which makes
their messages much more difficult to read using PINE.
Permalink | Reply | 2 comments |
headers
Internet-Drafts | 14 Mar 1996 17:06
Picon
Picon

I-D ACTION:draft-ietf-822ext-mime-imt-04.txt

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Internet Message Extensions 
Working Group of the IETF.                                                 

       Title     : Multipurpose Internet Mail Extensions (MIME) Part Two:  
                   Media Types                                             
       Author(s) : N. Borenstein, N. Freed
       Filename  : draft-ietf-822ext-mime-imt-04.txt
       Pages     : 51
       Date      : 03/13/1996

STD 11, RFC 822 defines a message representation protocol specifying 
considerable detail about US-ASCII message headers, but which leaves the 
message content, or message body, as flat US-ASCII text.  This set of 
documents, collectively called the Multipurpose Internet Mail Extensions, 
or MIME, redefines the format of messages to allow for                     

 (1)   textual message bodies in character sets other than US-ASCII,        
 (2)   an extensible set of different formats for 
       non-textual message bodies,     
 (3)   multi-part message bodies, and    
 (4)   textual header information in character sets other than US-ASCII.

These documents are based on earlier work documented in RFC 934, STD 11, 
and RFC 1049, but extends and revises them.  Because RFC 822 said so little
about message bodies, these documents are largely orthogonal to (rather 
than a revision of) RFC 822.                                               

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 14 Mar 1996 17:06
Picon
Picon

I-D ACTION:draft-ietf-822ext-mime-conf-05.txt

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Internet Message Extensions 
Working Group of the IETF.                                                 

       Title     : Multipurpose Internet Mail Extensions (MIME) Part Five: 
                   Conformance Criteria and Examples                       
       Author(s) : N. Borenstein, N. Freed
       Filename  : draft-ietf-822ext-mime-conf-05.txt
       Pages     : 28
       Date      : 03/13/1996

STD 11, RFC 822, defines a message representation protocol specifying 
considerable detail about US-ASCII message headers, and leaves the message 
content, or message body, as flat US-ASCII text.  This set of documents, 
collectively called the Multipurpose Internet Mail Extensions, or MIME, 
redefines the format of messages to allow for       

(1)   textual message bodies in character sets other than US-ASCII,        
(2)   an extensible set of different formats for 
      non-textual message bodies,    
(3)   multi-part message bodies, and  
(4)   textual header information in character sets other than US-ASCII.  

These documents are based on earlier work documented in RFC 934, STD 11, 
and RFC 1049, but extends and revises them.  Because RFC 822 said so little
about message bodies, these documents are largely orthogonal to (rather 
than a revision of) RFC 822.                                               

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 14 Mar 1996 17:07
Picon
Picon

I-D ACTION:draft-ietf-822ext-mime-imb-06.txt

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Internet Message Extensions 
Working Group of the IETF.                                                 

       Title     : Multipurpose Internet Mail Extensions (MIME) Part One:  
                   Format of Internet Message Bodies                       
       Author(s) : N. Borenstein, N. Freed
       Filename  : draft-ietf-822ext-mime-imb-06.txt
       Pages     : 35
       Date      : 03/13/1996

STD 11, RFC 822, defines a message representation protocol specifying 
considerable detail about US-ASCII message headers, and leaves the message 
content, or message body, as flat US-ASCII text.  This set of documents, 
collectively called the Multipurpose Internet Mail Extensions, or MIME, 
redefines the format of messages to allow for       

 (1)   textual message bodies in character sets other than US-ASCII,        
 (2)   an extensible set of different formats for 
       non-textual message bodies,  
 (3)   multi-part message bodies, and   
 (4)   textual header information in character sets other than US-ASCII.  

These documents are based on earlier work documented in RFC 934, STD 11, 
and RFC 1049, but extends and revises them.  Because RFC 822 said so little
about message bodies, these documents are largely orthogonal to (rather 
than a revision of) RFC 822.                                               

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald.T.Alvestrand | 15 Mar 1996 11:02
Picon
Picon

Re: Quoted-Printable - 8bit - sendmail (fwd)

Bernstein is currently using the kind of arguing he became famous
for in the DRUMS WG on a lot of Email issues, probably including
this one.

Please don't push his opinions (in which he is often alone) all over
the place.

Besides, Sendmail gives you "EightBitMode=a" which seems to do
the "right thing" (I think).

          Harald A
Permalink | Reply | 0 comments |
headers
Donald E. Eastlake 3rd | 15 Mar 1996 16:31

Mail Ubiquitous Security Extensions..

A BoF was held at the LA IETF meeting at which a draft was distributed 
in hard copy having the following abstract:

"Secure electronic mail can provide authentication of the source of mail and
confidentiality for its contents.  These features are becoming increasingly
important as the Internet expands. However, use of secure mail is still rare
due to the problems of key distribution and lack of migration to secure mail
enabled user agents.  This draft proposes partial solutions to these two
problems by using coarser grained identity to permit authentication and
confidentiality without user agent change, and DNS security for key
distribution." 

A slightly polished version of this draft will be sent to Internet Drafts
within a few days.  A mailing list has been set up which should be open for
discussion in a few days possibly leading to the formation of a Working
Group.  You can subscribe by sending mail to majordomo <at> imc.org with
"subscribe ietf-muse" in the body. 

Donald 
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee <at> cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee <at> world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html
Permalink | Reply | 0 comments |

Gmane