headers
Internet-Drafts | 4 Jun 1996 15:33
Picon
Picon

I-D ACTION:draft-ietf-822ext-mime-hdrs-00.txt

A New 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     : MIME (Multipurpose Internet Mail Extensions) Part Three:
                   Message Header Extensions for Non-ASCII Text            
       Author(s) : K. Moore
       Filename  : draft-ietf-822ext-mime-hdrs-00.txt
       Pages     : 14
       Date      : 06/03/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.                                       

This particular document is the third document in the series.  It describes 
extensions to RFC 822 to allow non-US-ASCII text data in Internet mail 
header fields.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald.T.Alvestrand | 14 Jun 1996 15:59
Picon
Picon

nonexistent-WG Last Call on MIME documents

Folks,
the time has come to move on the next step of the MIME documents.

The proposal on the table before us is:

There exist 6 new drafts, with the following names and proposed grade:

draft-ietf-822ext-mime-imb-06.txt	- Draft
draft-ietf-822ext-mime-imt-04.txt	- Draft
draft-ietf-822ext-mime-hdrs-00.txt	- Draft
draft-ietf-822ext-mime-reg-03.txt	- BCP
draft-ietf-822ext-mime-conf-05.txt	- Draft
draft-freed-charset-reg-00.txt		- BCP

Most of these have been out for quite a while, and what initial discussion
there was has largely died down.

There is no active working group that has within its scope a mandate to
review these documents.

What I propose is this:

- All of the interested parties, read the documents NOW.
- If discussion on this list provokes no strong reactions against the
  current text of the document, issue an IETF-wide Last Call.

I propose a deadline for discussion on this list of ***** JULY 4, 1996.*****
(which will give me time to get back from the IETF and catch my breath)
At this time, if no significant (in the minds of me and Keith) objections
to the documents have been raised, the IETF-wide Last Call (4-week)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Crocker | 19 Jun 1996 05:28
Picon

Re: Last Call: Standard Electronic Mail Addresses For Internet Operations

Folks,

	I'm sending this to express very strong support for the draft
document, "Standard Electronic Mail Addresses For Internet Operations".  It
is about time someone codified email addresses for common use on the net
and it's great that Paul did the deed.  This document needs to be published.

	It needs to be published... after undergoing two kinds of changes:

1.  	As the title of the document states, it is declaring a standard.
In particular, it specifies classic "protocol" details in that it defines a
basis for interoperability between end-users, namely the rendezvous
information needed to get that interoperability.  This is not merely a
matter of operations practise, but rather of formal, public, and rigorous
definition and registration of mailbox names to be used without special
arrangement.  Is Port 25 only a BCP?  I think not.

	As such, this document needs to be published as a full Internet
standard, not merely as a BCP.  Instead of simply listing a range of
addresses that exist around the net, it should put the imprimateur of
formal definition -- and formal expection and status -- on important
mailbox names.

2.	Unfortunately, some of the addresses in the current document do NOT
represent current practise or they have some (minor) problems.  Also, there
are redundant addresses, without a strong indication of their having
thoroughly entrenched installed bases.

	Some examples that I've noticed, so far are:
(Continue reading)

Permalink | Reply | 501 comments |
headers
Robert Elz | 19 Jun 1996 06:07
Picon

Re: Last Call: Standard Electronic Mail Addresses For Internet Operations

    Date:        Tue, 18 Jun 1996 20:28:46 -0700
    From:        Dave Crocker <dcrocker <at> imc.org>
    Message-ID:  <v03007402adecc733155d <at> [205.214.160.85]>

    Is Port 25 only a BCP?  I think not.

Actually, yes, that is exactly what it should be.   Ignoring "BCP" as
it now is for one minute, the real need when the doc series was extended
was to have a category of docs that are, for all practical purposes,
standards, but for which the rules for STD could not apply.   Ie: is it
possible to have 2 independant implementations of (the definition of)
port 25?   Somehow, I think not.   Similarly, is it possible to have a
new PS or DS for port 25, giving it a different meaning (perhaps shade of
meaning) while retaining a previous STD that existed before, so that some
can implement the new version, and others the old.   Again, I suspect not.

This doc series (which has been labelled BCP) is needed to fill this gap,
standards that can't go through multiple levels of implementation status,
as they're either used, or they're not, and which can't exist in parallel
with some earlier version of the same thing.   The definitions of port
numbers (and e-mail addresses, if this happens) are exactly the kind of
thing that this doc series should be used for.

What it shouldn't be being used for is docs that are really just
informational ("this is what we do") which someone wants to seem more
important ("this is what we do, and this other bunch of people agreed
that this is what we do...").    That is all just information.

    2.	Unfortunately, some of the addresses in the current document do NOT
    represent current practise or they have some (minor) problems.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Rens Troost | 19 Jun 1996 22:51

Re: nonexistent-WG Last Call on MIME documents

> Date: Wed, 19 Jun 1996 16:07 EDT
> Sender: owner-ietf-822 <at> list.cren.net
> Precedence: bulk
> From: hansen <at> pegasus.att.com
> To: ietf-822 <at> list.cren.net
> Subject: Re: nonexistent-WG Last Call on MIME documents
> Content-Type: text
> X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN
> 
> < the time has come to move on the next step of the MIME documents.
> 
> The only problem I have with the proposed documents is the lack of treatment
> of the content-disposition header. Rfc 1806 needs to be moved into the
> standards track along with these MIME documents. The features of MIME which
> were removed in favor of placing them in the content-disposition header
> (e.g., Content-Type: name= -> Content-Disposition: filename=) are needed in
> the community, and we need a standards track method of dealing with those
> features.
> 
> 					Tony Hansen
> 			  hansen <at> pegasus.att.com, tony <at> attmail.com
> 		    http://ourworld.compuserve.com/homepages/Tony_Hansen
> 

I have a draft with a couple of added features (file modes, etc.) If
there are no objectiosn Ill submit it. It dawns on me I was going to
do that before the LAST ietf. Ugh. time flies.

-Res
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Gardiner Myers | 19 Jun 1996 22:56
Picon
Favicon

Re: nonexistent-WG Last Call on MIME documents

I had sent the following comments to the author of
draft-ietf-822ext-mime-hdrs-00.txt; I would like them resolved before
moving to IETF Last Call.

The first one is mostly editorial; the last two deal with the problem
that a mail reader technically needs to have an arbitrary amount of
lookahead in order to determine whether linear-white-space following
an encoded-word should be output or not.

>  75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may

....(separated by CRLF LWSP-char)...

>       When displaying a particular header field that contains multiple
>       'encoded-word's, any 'linear-white-space' that separates a pair of
>       adjacent 'encoded-word's is ignored.  (This is to allow the use of

....'encoded-words's, any amount up to 75 octets of
'linear-white-space' that separate...

(at end of paragraph) Mail readers may choose to ignore between
adjacent 'encoded-word's sequences of 'linear-white-space' that are
longer than 75 octets.

--

-- 
_.John G. Myers		Internet: jgm+ <at> CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From erik <at> netscape.com Wed Jun 19 17:21:13 1996
Received: from urchin.netscape.com (h-198-95-250-59.netscape.com [198.95.250.59]) by
list.cren.net (8.6.12/8.6.12) with ESMTP id RAA17149 for <ietf-822 <at> list.cren.net>; Wed, 19 Jun 1996
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 20 Jun 1996 16:28

Re: nonexistent-WG Last Call on MIME documents

On 6/20/96 at 5:43 AM -0500, Harald.T.Alvestrand <at> uninett.no wrote:

>rens <at> name.net said:
>> I have a draft with a couple of added features (file modes, etc.) If
>> there are no objectiosn Ill submit it. It dawns on me I was going to
>> do that before the LAST ietf. Ugh. time flies.
>
>There were also some candidate new features suggested in
>the MIXER WG; someone took an action to bring
>it to your attention.
>Did you get them?

That was me. I got them to Steve Dorner, and he was to pass along the edits
to Rens and then get the draft submitted. I was remiss in my "being a pain
in the butt" responsibilities.

>They were creation-date, modification-date, read-date and size;
>all dates in RFC-822 syntax, size in bytes.

Yes, I actually saw a copy of the language that Steve wrote for these.

pr

--
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated
Home: (217)337-1905 / Fax: (217)337-1980
Permalink | Reply | 0 comments |
headers
Rens Troost | 23 Jun 1996 06:30

Content-Disposition Charset Punt

The only bugbear left in the Content-Disposition woods is the desire on
the part of many to have charset support for the filenames. The
current draft punts:

    Current [RFC 1521] grammar restricts parameter values (and
    hence Content-Disposition filenames) to US-ASCII.  We
    recognize the great desirability of allowing arbitrary
    character sets in filenames, but it is beyond the scope of
    this document to define the necessary mechanisms.  We expect
    that the basic [RFC 1521] `value' specification will someday
    be amended to allow use of non-US-ASCII characters, at which
    time the same mechanism should be used in the Content-
    Disposition filename parameter.

In the interests of expediency, I want to stick with this wording and
approach. It was in no small part turmoil over this issue that caused
it to be issued as Experimental in the first place, so I wanted to run
this by the group.

-Rens
From Ned.Freed <at> innosoft.com Sun Jun 23 03:28:10 1996
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net
(8.6.12/8.6.12) with ESMTP id DAA17384 for <ietf-822 <at> list.cren.net>; Sun, 23 Jun 1996 03:28:09 -0400
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694)
 id <01I67UDVV4Q8ADCZ13 <at> INNOSOFT.COM>; Sun, 23 Jun 1996 00:27:09 -0700 (PDT)
Date: Sun, 23 Jun 1996 00:13:33 -0700 (PDT)
From: Ned Freed <Ned.Freed <at> innosoft.com>
Subject: Re: nonexistent-WG Last Call on MIME documents
In-reply-to: "Your message dated Fri, 14 Jun 1996 15:59:53 +0200"
 <17804.834760793 <at> domen.uninett.no>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane