ietf-822
[Top] [All Lists]

Re: Character-set header (was Re: Minutes of the Atlanta 822ext meeting)

1991-09-09 19:16:56

Date:         Fri, 6 Sep 1991 15:11:55 PDT
From: Bill Janssen <janssen(_at_)parc(_dot_)xerox(_dot_)com>
Subject: Re: Character-set header (was Re: Minutes of the Atlanta 822ext 
meeting)

Excerpts from ext.ietf-822: 6-Sep-91 Re: Character-set header (w.. Neil
Katin(_at_)eng(_dot_)sun(_dot_)com (1816)

Frame can write its documents out in several formats; one format is
SGML-like, is encoded using ascii, and is called Maker Interchange Format.
Another is an "internal" format that represents the same information
but is quicker to parse and more compact on disk.  It is not human
readable and fits into our "binary" category with respect to transport
encoding because it does not have line length limitations.

While these two formats should have different subtypes, it seems clear
to me that they should have the same type, because they represent the
same information.

In a standards document, it is important to be clear about what things
are for.  In this case, we still have confusion about what the "type"
field of "Content-Type" is used for.  Originally, it was intended to
represent the type of document being sent; i.e. whether it was a text
document, or an image, or whatever.  Neil's comment is correct in that
context.

However (if I understand all this properly) the "type" field is now used
to partition the space of possible formats, to indicate what kind of
transport encodings might have to be applied to allow a message of that
"type" to be properly transmitted.  It is no longer correlated with the
document type, other than accidentally.  That is to say, the two
variants of FrameMaker format are two different formats, and fall into
different "type" partitions.  The ASCII form would fall into TEXT or
TEXT-PLUS (I believe that both imply 7BIT, so I find it hard to see the
difference between them?), and the binary form would come under BINARY
or APPLICATION or some such (which implies BASE64, presumably).

If we decided this, I never heard about it.  Isn't this exactly
what the spec says that transport encodings is for?  I know that
someone proposed a change like this, but I never thought it was
accepted.  Did I miss a step?

        Neil

<Prev in Thread] Current Thread [Next in Thread>