headers
Olle Jarnefors | 3 Oct 1994 16:22
Picon
Picon

Bug in RFC 1522

> Network Working Group                                           K. Moore
> Request for Comments: 1522                       University of Tennessee
> Obsoletes: 1342                                           September 1993
> Category: Standards Track
> 
> 
>          MIME (Multipurpose Internet Mail Extensions) Part Two:
>               Message Header Extensions for Non-ASCII Text

> 2. Syntax of encoded-words
> 
>    An "encoded-word" is defined by the following ABNF grammar.  The
>    notation of RFC 822 is used, with the exception that white space
>    characters MAY NOT appear between components of an encoded-word.
> 
>    encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
> 
>    charset = token    ; see section 3
> 
>    encoding = token   ; see section 4
> 
>    token = 1*<Any CHAR except SPACE, CTLs, and especials>
> 
>    especials = "(" / ")" / "<" / ">" / " <at> " / "," / ";" / ":" / "
>                <"> / "/" / "[" / "]" / "?" / "." / "="

The second last line is syntactically malformed and should be,
I think:

:    especials = "(" / ")" / "<" / ">" / " <at> " / "," / ";" / ":" / "\" /
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Moore | 3 Oct 1994 16:39
Picon

Re: Bug in RFC 1522

> >    especials = "(" / ")" / "<" / ">" / " <at> " / "," / ";" / ":" / "
> >                <"> / "/" / "[" / "]" / "?" / "." / "="
> 
> The second last line is syntactically malformed and should be,
> I think:
> 
> :    especials = "(" / ")" / "<" / ">" / " <at> " / "," / ";" / ":" / "\" /

 
You are correct.  This is probably a typo in the troff source.

My preference would be to fix this when MIME advances (or attempts
to advance) to Full Standard, and issue a new RFC at that time.

Keith Moore
Permalink | Reply | 0 comments |
headers
edbjs | 11 Oct 1994 09:22
Picon

REF: INTERNET=EDBJS <at> FT.DK


         Date: 10/11/94
         From: John Skovgaard Sxrensen                      EDBJS    - FT      
      Subject: REF: INTERNET=EDBJS <at> FT.DK                                        

         Nu svarer jeg den tekst jeg har feet via Internet FRA VMSmail.

         Slut

           To:                                              00000    - INTERNET
Permalink | Reply | 0 comments |
headers
Kazuhiko Yamamoto 山本和彦 | 14 Oct 1994 04:07
Picon

MIME compression mechanism

Hi all,

# Let me know if this is a wrong place.

I have read rfc1521 and draft-ietf-822ext-mime-imb-00.txt but I can't
find compression mechanism for MIME. As you know, picture or audio
data is too large. So, I think compression mechanism is very important
for MIME.

If current MIME has no compressin mechanism, I'd like to suggest a
subtype -- "compression" -- for Content-Transfer-Encoding:. For
example,

Content-Transfer-Encoding: Base64; Compression="gzip"

Thanks.

--Kazu
Permalink | Reply | 38 comments |
headers
Keith Moore | 14 Oct 1994 06:06
Picon

Re: MIME compression mechanism

> # Let me know if this is a wrong place.
> 
> I have read rfc1521 and draft-ietf-822ext-mime-imb-00.txt but I can't
> find compression mechanism for MIME. As you know, picture or audio
> data is too large. So, I think compression mechanism is very important
> for MIME.

Both picture and audio data usually need a compression algorithm that is
fine-tuned for the type of data being compressed.  A general-purpose
compression algorithm (like gzip or lzw) is usually ineffective for these
kinds of data.

In these case, it is best if the content-type defines the compression.  For
instance, image/jpeg and image/gif images are already in compressed form. 
Audio/basic is also compressed (in a sense) by the use of mu-law encoding to
reduce the number of bits required by each sample.  One can suppose that
additional image, audio, and video types to be defined in the future will
also incorporate compression as part of the content-type itself.

> If current MIME has no compressin mechanism, I'd like to suggest a
> subtype -- "compression" -- for Content-Transfer-Encoding:. For
> example,

Such a mechanism might be useful for other types *besides* audio, video, and
image.  However, it would be difficult to gain support for a compressed
content-trasnfer-encoding, because a body part encoded with a unknown
encoding would be unreadable by every existing MIME reader.

Keith Moore
(Continue reading)

Permalink | Reply | 16 comments |
headers
Masataka Ohta | 14 Oct 1994 15:32
Picon

Re: MIME compression mechanism

> I have read rfc1521 and draft-ietf-822ext-mime-imb-00.txt but I can't
> find compression mechanism for MIME. As you know, picture or audio
> data is too large. So, I think compression mechanism is very important
> for MIME.
> 
> If current MIME has no compressin mechanism, I'd like to suggest a
> subtype -- "compression" -- for Content-Transfer-Encoding:. For
> example,
> 
> Content-Transfer-Encoding: Base64; Compression="gzip"

Before the detailed discussion on compression, or binary data in
general, I'd like to confirm that there is a consensus that CTE of
8bit or binary of MIME MUST be able to handle code points of non
graphic characters of ISO 2022 including NULL, a zero byte.

Any objections?

							Masataka Ohta
Permalink | Reply | 19 comments |
headers
Keith Moore | 14 Oct 1994 06:47
Picon

Re: MIME compression mechanism

> > Such a mechanism might be useful for other types *besides* audio, 
> > video, and image.  However, it would be difficult to gain support 
> > for a compressed content-trasnfer-encoding, because a body part 
> > encoded with a unknown encoding would be unreadable by every 
> > existing MIME reader.
> 
> Please discuss spec and implementation issue separately. All MIME
> interfaces can't handle compressed MIME parts now. But when such a
> spec is defined, many MIME interfaces would support this mechanism.

Perhaps.  But the subject has come up before, and this objecection
has always been raised when it did.

New content-transfer-encodings can be defined, but must be approved in a
standards-track RFC, which in turn requires the consensus of an IETF working
group.

By contrast, *changes* to the MIME grammar for the content-transfer-encoding
(like the one you proposed in your earlier message to combine base64 and a
compression algorithm) are probably even more difficult to acheive.

I am on record as being in favor of a "gzip" content-transfer-encoding.
The next step would be for someone to write up a specification for it,
and see if it can gain working group approval.

--
Keith Moore                                     NETLIB development group
Computer Science Department / University of Tennessee at Knoxville
107 Ayres Hall / Knoxville TN 37996-1301
Let's stamp out the content-length header in our lifetime.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Kazuhiko Yamamoto 山本和彦 | 14 Oct 1994 06:33
Picon

Re: MIME compression mechanism

From: Keith Moore <moore <at> cs.utk.edu>
Subject: Re: MIME compression mechanism 
Date: Fri, 14 Oct 1994 01:06:32 -0400

> > I have read rfc1521 and draft-ietf-822ext-mime-imb-00.txt but I can't
> > find compression mechanism for MIME. As you know, picture or audio
> > data is too large. So, I think compression mechanism is very important
> > for MIME.
> 
> Both picture and audio data usually need a compression algorithm that is
> fine-tuned for the type of data being compressed.  A general-purpose
> compression algorithm (like gzip or lzw) is usually ineffective for these
> kinds of data.
> 
> In these case, it is best if the content-type defines the compression.  For
> instance, image/jpeg and image/gif images are already in compressed form. 
> Audio/basic is also compressed (in a sense) by the use of mu-law encoding to
> reduce the number of bits required by each sample.  One can suppose that
> additional image, audio, and video types to be defined in the future will
> also incorporate compression as part of the content-type itself.

Sorry, examples are wrong. My motivation is to compress text/plain,
message/rfc822, application/postscript, and application/octet-stream.

> > If current MIME has no compressin mechanism, I'd like to suggest a
> > subtype -- "compression" -- for Content-Transfer-Encoding:. For
> > example,
> 
> Such a mechanism might be useful for other types *besides* audio, video, and
> image.  However, it would be difficult to gain support for a compressed
(Continue reading)

Permalink | Reply | 15 comments |
headers
Keith Moore | 14 Oct 1994 08:02
Picon

Re: MIME compression mechanism

> 
> Before the detailed discussion on compression, or binary data in
> general, I'd like to confirm that there is a consensus that CTE of
> 8bit or binary of MIME MUST be able to handle code points of non
> graphic characters of ISO 2022 including NULL, a zero byte.

(why do I feel like we're about to get hit over the head with something?)

With the exception of a couple of warts in quoted-printable,
content-transfer-encodings don't care what kind of data is being encoded. 
It can be audio or video or iso-2022 or unicode or whatever.  Any kind of
data *can* be encoded with any c-t-e; the reason you pick one c-t-e over
another is to ensure robustness during transmission.

Specifically, either 8BIT or BINARY content-transfer-encoding can be used to
encode a 0x00.  However, I doubt seriously that using the 8BIT label on a
body part that contains bare NULs is sufficient to protect the integrity of
that body part when handled by the various systems out there that recognize
the 8BIT content-transfer-encoding.  BINARY labelling would be more
appropriate for body parts that contain 0x00 octets.

Anyway, I don't think you have the consensus you were looking for.
(But I'm sure you will push on anyway...)

Keith
Permalink | Reply | 18 comments |
headers
Kazuhiko Yamamoto 山本和彦 | 14 Oct 1994 15:11
Picon

Re: MIME compression mechanism

From: Keith Moore <moore <at> cs.utk.edu>
Subject: Re: MIME compression mechanism 
Date: Fri, 14 Oct 1994 01:47:20 -0400

> New content-transfer-encodings can be defined, but must be approved in a
> standards-track RFC, which in turn requires the consensus of an IETF working
> group.
> 
> By contrast, *changes* to the MIME grammar for the content-transfer-encoding
> (like the one you proposed in your earlier message to combine base64 and a
> compression algorithm) are probably even more difficult to acheive.
> 
> I am on record as being in favor of a "gzip" content-transfer-encoding.
> The next step would be for someone to write up a specification for it,
> and see if it can gain working group approval.

O.K. I understand that defining new subtype for
Conetnt-Transfer-Encoding fails into grammar change. But defining new
value for it like "Base64+gzip" is not beautiful because encoding and
compression are orthogonal concepts.

So how about a new MIME field like Content-Transfer-Compression?

--Kazu
Permalink | Reply | 12 comments |

Gmane