ietf-822
[Top] [All Lists]

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

1991-09-06 15:12:36
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).

Excerpts from ext.ietf-822: 6-Sep-91 Re: Character-set header (w.. Mark
Crispin(_at_)marge(_dot_)cac(_dot_)w (1514)

     RFC-XXXX should expressly forbid the use of any subtype not listed in
RFC-XYZA unless the subtype is prefixed with X-vendor-.  X-vendor- subtypes
are expressly documented as non-interoperable, and to be used only for
development purposes prior to the assigning of a registered subtype.

Good idea.  Will all X-vendor subtypes be sub-types of APPLICATION, or
will the vendor be obliged to choose the correct "type" partition for
the encoding needs of their format?

Bill