ehall@xxxxxxxxx (Eric A. Hall) wrote on 13.08.04 in <411CDF3E.7000507@xxxxxxxxx>: > Keith Moore <moore@xxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf