Ned -
First, forgive the tone of my messages last night, I was in a bad mood
trying to implement from the new draft and being very confused by what the new
draft really is saying. I am still confused, but am starting to believe the
draft is even more confused.
You are correct, the issue is one of syntax, but it means something
majorly important to my parser. It means that I don't have to worry about
character sets as a top-level concept for every possible type. It's the
difference between having a charset member of a body structure, and the
charset being stashed away in a parameter list. It's a cleaner and less
ambiguous syntax.
Here's what I fundamentally want to do. I want to simplify and
consolidate the BNF as follows:
Content-Type := type *["/" subtype] *[";" attribute "=" value]
attribute := token
subtype := token
value := token / quoted-string
type := "TEXT" / "TEXT-PLUS" / "MULTIPART" / "BINARY" /
"APPLICATION" / "MESSAGE" / "AUDIO" / "IMAGE" / "VIDEO" /
x-token
This is a much cleaner, more consistent syntax. It also would have
prevented the fiasco with the change to MULTIPART's parameters. The
implication of this is something like:
Content-Type: TEXT; charset=US-ASCII
Content-Type: MESSAGE/RFC822
Content-Type: MULTIPART; boundary=owatagusiam
The benefits of this is that instead of the present inconsistent form
that parameters take, I would have a list of attribute/value pairs. Lisp fans
would recognize it as a fundamental structure, but it's a convenient mechanism
even in C. It allows me to parse parameters into a usable form instead of
being stuck with a list of token/quoted-strings.
As for ISO-2022, all that is needed right now is for RFC-XXXX to define
it as a subtype of TEXT (note!! *not* a charset!), that is:
Content-Type: TEXT/ISO-2022
and allow the ISO-2022 community to define whatever extensions or restrictions
they wish. What the above should mean is `text formatted according to ISO-
2022.' Now, it is probable that most users of ISO-2022 are only capable of
understanding a subset and some restrictions are necessary. But let *us*
worry about it. These concerns are only of interest to the receiver of an
ISO-2022 message.
I should note that *every* message that originates from an ISO-2022 UA
will probably be tagged as ISO-2022 even if it doesn't use ISO-2022
internally. That is, ISO-2022 is a superset of US-ASCII. Other than
identifying that there *may* be a problem with displaying the message a UA
reading the message should display it as best it can.
I will predict right now that 99.9% of the ISO-2022 usage on the Internet
will be to convey Japanese text in 7-bits. ISO-2022 isn't used much for
Chinese (in fact, I don't think it can be used for the Taiwanese BIG5
charset). Japanese use of ISO-2022 is well understood. The specification for
it does NOT belong in RFC-XXXX though.
I object to restricting tspecials from boundary-specs. I use a tspecial
now in my boundary-specs. MTR wants something even more general. I believe
that anything within the limitations of a quoted-string should be allowed, as
it was before.
How do `not making ALTERNATIVE required' and `recognition of ALTERNATIVE
as a valid subtype of MULTIPART but leave implementation up to the UA' differ?
The reason for the sampling rate being an integer is that's how the .snd
file header defines it. In actuality, 8012 isn't the actual sampling rate,
but it's the closest that can be put in there. Compatibility ;-(
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.
What are you referring to here?
The new draft requires
Content-Type: TEXT/US-ASCII
Body-Version: RFC-XXXX
in all messages, to be conformant with the new standard, whether or not any of
the fancy stuff is used.
-- Mark --