ehall(_at_)ehsco(_dot_)com (Eric A. Hall) wrote on 13.08.04 in
<411CDF3E(_dot_)7000507(_at_)ehsco(_dot_)com>:
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote on Thu, 12 Aug 2004
08:45:24 -0400:
this is an application for a media-type. it's not trying to define the
mbox format, it's just trying to define a label for the mbox format
that can be used in contexts where MIME media-type labels are required.
That's correct; this is a tag definition, not a format specification.
That is not the problem. The problem is that the tag is not specific
enough to be useful.
There are a few places where this tag is necessary or useful. Online
downloadable archives of mailing lists would be easier to import, search
and otherwise manipulate if a media-type were defined and which allowed a
transfer agent to bridge the data to a local content agent
... but absent specification of *which* mbox format it is, this can only
work by luck.
A definitive authoritative specification for all variations of the mbox
database format is explicitly not the objective, for several reasons.
Note that I never asked for that. (Unless you think the variant of mbox in
use could only specified if we had that specification, that is ... which
would only underscore the gaping hole in the current document.)
(Note also that I didn't ask for any specific way of specifying the mbox
variant - the regular expression proposal was someone else, and I'm not
convinced it actually solves the problem.)
Suggestions about parameters has come up before (John Klensin suggested it
to me a couple of months ago). Unfortunately, these kind of helper tags
attempt to define content rules rather than transfer rules, and therefore
represent a non-trivial layer violation.
That seems nonsensical. They're no more or less defining content rules
than the media type itself is.
They are analogous to using a
"version=" tag for app/postscript and relying on that meta-information
instead of embedded clue data.
It seems well established that "embedded clue data" for mbox is not
reliable, unless you involve a full AI.
In any case, I really don't see the qualitative difference between
claiming "this is XHTML text" and "this is HTML 4.1 text", to pick a
different example.
I think claims of "layer violation" are clearly - and obviously - wrong.
There *is* no non-artificial layer boundary here. The boundary in question
is completely arbitrary.
Obviously, content agents should be aware
of the content formatting rules. [what happens when the helper meta-tags
are lost? should the content agent NOT look at the content to make a
determination?
Not without asking a human, it probably shouldn't. It's far too easy to
get it wrong.
that's where the logic belongs in the first place, so
putting it into the transfer layer is not only irrelevant it is possibly
harmful.]
Attempting to automatically figure this out is the harmful version.
Telling what it is is most certainly *NOT* harmful.
MfG Kai
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf