[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on latest MIME drafts
- To: ietf-822@xxxxxxxxxxxxxxxxxx
- Subject: Re: comments on latest MIME drafts
- From: John Gardiner Myers <jgm+@xxxxxxx>
- Date: Fri, 9 Jun 1995 16:58:56 -0400 (EDT)
- Beak: Is
- In-reply-to: <>
- References: <> <><><><>
Ned Freed <NED@SIGURD.INNOSOFT.COM> writes:
> > Having the semantics be associated with identifiable syntactic objects
> > simplifies the task of generating and reading the data format.
> > Composers generate the syntactic constructs corresponding to the
> > semantics they want to convey. Readers discover semantics by first
> > doing a parse to discover the syntax, then applying the association of
> > semantics to particular syntactic objects.
> I disagree 100% with all of this. People do not discover sematics by
> implementing parsers. They discover them by reading specifications.
The specification of a format has to give sufficient information about
how to write programs to both generate and read objects in the format.
Anyone implementing anything which reads MIME objects is implementing
> But it certainly isn't necessary for semantics to exist, nor is it
> necessary for different semantic constructs to bind unique syntactic
> elements. In fact it can be quite the opposite -- dates appear in
> all sorts of places in header fields, but I don't hear anyone
> suggesting that the semantics of date need to be represented
> differently in all of these fields or that dates are not important
> entities semantically.
I think you're misunderstanding what I'm saying.
The date-time nonterminal in RFC 822 has certain semantics associated
with it, these semantics are common to all occurences of date-time in
other nonterminals. The date-time nonterminal occurs in quite a
number of other nonterminals, those other nonterminals have their own
additional semantics which are relevant to the date-time.
The semantics that identify a particular point in time are associated
with the date-time nonterminal and the nonterminals underneath
date-time. The semantic that identifies that point as being the time
of message creation is associated with the orig-date nonterminal. The
semantic that identifies that point as being the time of message
transport is associated with the received nonterminal.
> > The semantics they have in common (header/body syntax, content-
> > headers) I am trying to associate with the syntactic object known as
> > an "entity".
> And I think this is a very bad idea. Entities are more general than this.
I think what you call an "entity" is different from what I call an
The definition of "body part" you suggested in your message of May 30
is actually very close to what I would call an "entity". Perhaps a
entity = *(field / content-field) [ CRLF *OCTET ]
content-field = content / encoding / id /
description / mime-extension-field
would make the semantic associations clearer?
> > The semantics specific to a body part (contained in a multipart, does
> > not require MIME-Version, may not contain enclosing multipart's
> > delimiter) I am trying to associate with the syntactic object known as
> > a "body-part", which is a disjoint subset of an "entity".
> And this flies in the face of common usage, common understanding,
> and common sense. It makes MIME much harder to understand, and I am
> not willing to do it. This is an absolute showstopper for me.
I have absolutely no idea where your statement is coming from. These
semantics have existed since 1341 and everything that deals with a
multipart has to know about them. Most of them have been specifically
attached to the definition of the body-part nonterminal.
It is the idea of having the term "body part" refer to something other
than the "body-part" BNF nonterminal that defies common sense and
makes MIME much harder to understand.
> > They have some syntax (and associated semantics) in common, and they
> > have some syntax (and associated semantics) by themselves.
> But they also each have their own semantics as well as their own syntax.
So you stick the common syntax and semantics on the common
nonterminals/terms and stick their own syntax semantics on their own
> > Actually, I don't think the meaning of the term is well understood.
> > It appears to be used for at least two different concepts.
> Well, if you mean that there's a well understood common sense meaning that
> is what most people mean when they say "body part", versus the old,
> nonsensical definition that managed to slip into MIME, then I certainly
> > I think it's a bit confusing. It also defines a term that is
> > a different concept than the body-part syntactic object, which has
> > semantics which do not apply to messages.
> What semantics does it have that don't apply to MIME messages?
The semantics associated with a body-part syntactic object, which do
not apply to messages are:
* Does not require a MIME-Version header field
* May not include the boundary delimiter line of the enclosing
> The Working Group rejected exactly this paradigm some time ago, preferring
> instead to go with the approach of MIME messages being a proper subset of
> RFC822 messages.
At some point we have to learn from our mistakes.
> > RFC 1049 Content-Type:
> > headers are not syntactically legal MIME Content-Type: headers, so a
> > MIME reader has the freedom to treat RFC 1049 Content-Type: headers as
> > it likes.
> Not if it treats all messages as MIME messages.
MIME does not specify how one must treat syntactically illegal
Content-Type: headers. Nothing in MIME prevents a reader from
interpreting syntactically illegal Content-Type: headers as it likes.
This is true whether or not there is a MIME-Version: header.
Put another way, RFC 1049 can be considered an extension to MIME,
albeit one which MIME agents are not permitted to generate.
> > Even with the definition of "body part" in
> > draft-ietf-822ext-mime-imb-03.txt, messages which "aren't MIME
> > messages" have associated body parts. Take the (presumably zero)
> > content headers of the message, along with the body and there's your
> > "body part".
> Sure. This can happen in MIME messages as well.
So therefore rules which MIME defines for body parts apply to messages
which "aren't MIME", since those messages also have body parts. This
is no different than applying those rules to entities.
> > If a message doesn't have a MIME-Version, then a receiving UA has the
> > option, given in section 6 of the message bodies document, of ignoring
> > all rules in MIME applying to the message body, including any rules
> > imposed by the fact that the message is an entity.
> Sure, but so what?
This is the escape hatch. The MIME rules apply to all messages,
including those without MIME-Version. However, in the absence of
MIME-Version, those rules which would apply to the body can be
This escape hatch works equally well depending on whether the rules
are applied to "body parts" or "entities".
> > How does it lose? You apply all the rules that you want for both
> > messages and body-parts, including the various Content-* headers, to
> > entities. It appears to me to be a semantic win.
> Because it blurs the distinction between body parts and messages.
> The early MIME work presented us with substantial evidence that losing
> this distinction is very bad.
It actually clarifies the distinction between a body-part and a
message. Your approach blurs the distinction between a "body part"
and a body-part.
_.John G. Myers Internet: jgm+@CMU.EDU