--On Tuesday, 17 August, 2004 17:38 -0700 Dave Crocker
<dhc@xxxxxxxxxxxx> wrote:
> John,
>
>>> Global parameters are useless if the parser is intelligent
>>> enough to figure out the message structure independently.
>>> Given that such intelligence is a prerequisite to having a
>>> half-baked parser, the global parameters are always
>>> unnecessary.
>
> JCK> This is a minor point compared to the one below, and
> probably JCK> not an issue here, but I can't let the above
> stand.
>
>
> Actually, I suspect you (and we) can and should.
>
> A draft has been presented. Numerous objections from
> experienced folks have been lodged. Is there more productive
> discussion likely?
>
> This thread has not looked all that productive from the start
> and I am hard-pressed to see how that is going to change.
> Certainly countering arguments about the benefits of standards
> for labeling, semantics, and the like is not likely to
> convince anyone. If they don't see it, the only real question
> is what they are doing in this venue.
>
> Now, the real reason for my posting: If someone can summarize
> where this thread is going and/or should go, I'd appreciate it.
Well, I had planned to just stop after that note, on the theory
that the IESG should now have enough information to make
whatever decision they are inclined to make. My personal
recommendation, I trust obviously, is that they should say "no"
to this particular draft as a proposed standard: for
standardization purposes, it just isn't specific enough about
what is being transmitted.
If I were giving advice to the author, it would pretty closely
follow what I understand Keith to be suggesting. Withdraw this
document and the request that it be considered for PS. Generate
a new document that is very specific about how much or how
little can be assumed when something arrives with this content
type, makes it explicit that the receiver had better be prepared
to handle any of the various mbox forms, and points to whatever
documentation or other materials that can be easily identified
and might help in constructing a receiver-processor. I think
that document should be Informational, with a media type in some
non-IETF tree, but could personally live with a Proposed
Standard if the interoperability constraints, and any security
risks from guessing wrong about properties of the format were
extremely explicit.
Does that agree with your analysis, at least to a first order
approximation?
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf