ietf-822
[Top] [All Lists]

Re: comments on latest MIME drafts

1995-06-09 13:59:19
Ned Freed <NED(_at_)SIGURD(_dot_)INNOSOFT(_dot_)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
a parser.

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
"entity".

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
BNF of:

       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
nonterminals/terms.

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
agree.

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
  multipart

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
ignored.

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+(_at_)CMU(_dot_)EDU
                        LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

<Prev in Thread] Current Thread [Next in Thread>