In case anyone hasn't guessed, not having PostScript in some form is a
SHOW-STOPPER for me.
I agree as well. In fact, is there any value in distinguishing and
EPS enclosure (which might be rendered as a single image) vs. a
generic PostScript file (which may be composed of multiple pages)? If
I "knew" it was an EPS file, I'd just pop up a window and render it,
otherwise I fire up a real live PostScript previewer that can handle
multiple page documents.
A. 1: Audio formats - I'd prefer the body part to be self-identifying,
otherwise there's a question of the proper storage format.
I agree here; having the data be self-describing, especially when its
likely to be saved to a file and be treated as an opaque datatype by
some UAs that are not directly sound-capable.
A. 2: Checksums/Integrity Checks - if we're going to get this resolved in
Santa Fe, a strawman would be very helpful.
I'm not sure what the right answer is here, but I guess that I feel
pretty strongly that the checksum, where ever it might be used should
be end-to-end.
A. 3: Non-ASCII Headers - other than several suggestions to move this
out of RFC-XXXX, the silence is deafening. What's going on?
There were several demands for this earlier - if they are still
demands, I'd like to hear them before Santa Fe. Otherwise, punt.
It doesn't seem essential that the non-ASCII header issue be resolvod
to make progress on the rest of RFC-XXXX. This work can be done in
parallel.
B. 3: /alternative - someone must have a good reason for this to be
mandatory. This is not a SHOW-STOPPER, but I'd like to hear it.
I'm not sure if implementation should be mandatory, but being able to
transport, say, PostScript and simple ASCII text version of the same
data seems pretty valuable. The folks with high-capability UAs get
the "high- fidelity" version of the message, and those that don't get
the simple ASCII version. All automagically chosed by the UA. This
has been experimented with in a NeXT USENET news UA which posts the
ASCII text for the mundane UAs, but also provides RTF and imbedded
TIFF graphics for those folks using the fancy UA. It allows the two
communities to interact.
B. 7: Text-plus - again, not a SHOW-STOPPER, but this doesn't exactly
seem to be a Text sub-type. The Text-plus sub-types are dwindling,
but I still see a distinction at the top level.
It seems more a text subtype than something that stands alone to me.
I think one of the goals of text-plus was to be readable without
having software actually interpret the formatting directive. This
seems to be more varient of "text" than a different top-level body
part.
One other issue that I was thinking of - is the contents of the
Content-ID: field supposed to be globally unique, or just unique
within the message? I would assume that each Content-ID: should be
globally unique like the Message-ID: is. I ask because I'm thinking
about how one body part would reference another, and how this
interacts with digests of messages which might also have Content-ID:
headers imbedded in them.
Louis A. Mamakos
University of Maryland, College Park