ITEM
I do not like the way character sets are handled in the new draft. The
more I look at it, the less I like it. We now have two mechanisms; a subtype
of TEXT and the new Content-charset header. Both stick out as glaringly bad
design that need to be hit with bricks.
First brick is at the TEXT subtype. This precludes the use of the
subtype syntax for anything other than character sets. What's worse, it mixes
usages. It uses character set names such as US-ASCII or ISO-8859-xxx with
means of specifying character sets such as ISO-2022 and MNEMONIC.
Second brick is at Content-charset. This stands out forthrightly as a
poorly-thought out bad idea that is there only because some set of people
demanded it. It's meaningless for most of the types, which by itself is
justification enough to axe it.
Here is my proposal: character sets are specified as a parameter. The
syntax used for this is the `attribute = value' syntax used with types BINARY,
APPLICATION, AUDIO, IMAGE and video. This attribute will be called `charset'.
Entities that modify character sets but otherwise are not character sets, such
as MNEMONIC or ISO-2022, will continue to be subtypes of TEXT. This opens up
the possibility of folding TEXT-PLUS into TEXT, by making its subtypes be
subtypes of TEXT.
Here are some examples:
Content-Type: TEXT;charset=US-ASCII
Content-Type: TEXT;charset=ISO-8859-1
Content-Type: TEXT/ISO-2022
Content-Type: TEXT/RICHTEXT;charset=US-ASCII
Content-Type: APPLICATION/ATOMICMAIL;charset=ISO-8859-1
ITEM
I object to the characterization of ISO-2022 as `not recommended' and
incompletely specified. ISO-2022 is quite well-specified. Granted, its usage
is significantly narrower than its scope, but that's for the implementors and
users of ISO-2022 to worry about, not RFC-XXXX.
Barring any future documents which define scope-limiting mechanisms, it
should be assumed that there are no scope-limitations. Such a scope-limiting
mechanism might be:
Content-Type: TEXT/ISO-2022;charset=JIS-X0208.1983
which specified that the only recognized shift-in code is <ESC>$B [the shift-
out codes back to ASCII are <ESC>(J and <ESC>(B ] However, this does not need
to be documented here, and people should be able to interoperate as long as
they are allowed to use TEXT/ISO-2022.
ITEM
I object vehemently to the requirement that MULTIPART cookies (called
boundary-spec) be restricted to alphanum. I carefully build my cookes to be
impossible in BASE64 and QUOTED-PRINTABLE segments. Cookies should be defined
as 1*70<any CHAR except SPACE or CTLs>.
This is a major SHOW STOPPER for me.
ITEM
I object to making the ALTERNATIVE subtype of MULTIPART be REQUIRED for
conformance. It is a cute functionality, but it is extra baggage for
implementors to worry about.
ITEM
I have given long and hard thought to this, and I think that the DIGEST
subtype of MULTIPART should be excised from the standard. This is a band-aid
to help RFC-934. However, the exact same function is obtained with a regular
MULTIPART type with each of its parts being `Content-Type: MESSAGE'. What's
more, the latter is more flexible, since it allows a TEXT header for the
digest.
ITEM
The BNF for type MESSAGE on page 28 is broken, as it requires that either
the RFC822 or PARTIAL subtypes be given.
ITEM
The optionality of the second partnum of MESSAGE/PARTIAL is a bad idea.
Not many people are going to implement PARTIAL anyway, so you might as well be
tough on specifying an explicit syntax.
ITEM
The BNF for type APPLICATION on page 31 neglects to include the ODA
subtype. It also omits the ATOMICMAIL stuff that Andrew is using.
ITEM
The audio subtypes should include X-SUN and X-NEXT as well-known (and
equivalent) subtypes that are essentially U-LAW with a header as follows:
typedef struct {
int magic; /* must be equal to 0x2e736e64 */
int dataLocation; /* Offset or pointer to the raw data after header */
int dataSize; /* Number of bytes of data in the raw data */
int dataFormat; /* The data format code (1 = MULAW-8) */
int samplingRate; /* The sampling rate (generally 8012) */
int channelCount; /* The number of channels (generally 1) */
char info[4]; /* Textual information relating to the sound. */
} SNDSoundStruct;
ITEM
The restriction that text mail must have a Content-Type header with a
specific character set can never be enforced. I would prefer not to have
unenforcible requirements in RFC-XXXX, particularly ones that add extra header
lines for what users will feel is no good reason.
ITEM
As noted above, I object to the ALTERNATIVE subtype of MULTIPART be
mandatory.
ITEM
The richtext-to-text translator should be a routine to copy a source
richtext string to a target text string.
ITEM
In the BNF on page 43, attribute has = instead of :=
As noted above, the definition of boundary-spec needs to be fixed. It
even conflicts with examples in the text!
Body-Version is misplaced.
That's it for now.