Re: Update of the MIME-MHS Specs

Ned Freed <NED@sigurd.innosoft.com> Fri, 06 May 1994 17:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04297; 6 May 94 13:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04293; 6 May 94 13:57 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa09790; 6 May 94 13:57 EDT
Received: from SIGURD.INNOSOFT.COM by survis.surfnet.nl with SMTP (PP) id <07404-0@survis.surfnet.nl>; Fri, 6 May 1994 19:42:28 +0200
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HC0HIVAQSG8Y51FB@SIGURD.INNOSOFT.COM>; Fri, 6 May 1994 10:41:54 PDT
Date: Fri, 06 May 1994 10:20:39 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: Update of the MIME-MHS Specs
In-reply-to: Your message dated "Mon, 02 May 1994 16:05:08 -0700" <9405022305.AA05787@hideji.worldtalk.com>
To: csg@hideji.worldtalk.com
Cc: "Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no>, Steve Kille <S.Kille@isode.com>, mime-mhs@surfnet.nl
Message-id: <01HC0L8D8OQG8Y51FB@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit

> Etc.  One point of dispute would be whether different versions of the same
> application use different subtypes/OIDs; e.g., Word Prefect 4.x vs.  5.x.  I
> believe the original IETF ruling on this issue still applies.  (That is, if
> the application data contains its own version code or equivalent, as most of
> the above do, then putting a version number in the subtype or else- where in
> the header is redundant and evil.)

There's never been any such ruling. The question of how to handle versioning
information is much more complex than this, and cannot be answered based solely 
on whether or not there's version information in the format itself. Just
because a format is self-identifying as to some versioning scheme doesn't
mean this information is either necessary or sufficient to label the object.

The only case that has ever been dealt with is that of PostScript. In the case
of PostScript, it turns out that there's an extremely elaborate and precise
mechanism for describing what language facilities a given document uses within
the document itself. This information is so extensive and complex that there's
just no way it could be reasonably or usefully replicated in the content type
line.

Now, there is also a version number for PostScript. However, not only is it
inadequate for purposes of labelling, the PostScript language documents
explicitly state that it is meaningless and should never be used. There was
some talk of putting it in the content type line, but given the specification's
own position on this such an approach is literally indefensible.

> Another problem would be keeping the
> number of image, video, and audio subtypes under control; I claim that these
> should be as few as necessary to achieve interoperability, with mapping
> algorithms for common non-proprietary formats published.

This is, of course, just your position. Other people may disagree with it.

> An EMA committee member told me EMA wanted to do exactly this, and that Ned
> Freed attended an EMA BP15 meeting, but refused to work with the EMA, stating
> that "we already solved this problem."

Reality check time. For starters, not only did I agree to work with the EMA on
this, I invested considerable time and energy in writing a specification for
how to map FTBP into and out of MIME. I did this because the EMA seemed to
think it was useful, although I felt that a mapping from FTBP to specific MIME
types and back would better serve the community.

I dutifully turned the specification over to the EMA, with following results:
nothing happened.

Does this sound like "refused to work with the EMA" to you?

I will say that given what I think should be the outcome of a joint EMA-IETF
effort, I am not the right person to be doing the work that needs to be done.
I'm just a working group chair and a member of the application area
directorate. This really needs to be dealt with by the IESG and/or the IAB. I
provided the EMA with contact information for the people they should be talking
to in order to establish a liason. The result of this, as far as I can tell,
was the same: nothing happened.

> From a different source, I heard that
> the EMA people were insisting that MIME support BP15 OIDs and ASN.1 encoding
> in MIME body parts, which Ned and Jon Postel flatly shot down.

There was no such insistence. There was one person who mentioned this approach,
but it was quickly shot down by several other people. I didn't even have a
chance to state my opinion of it, as I recall. If Postel was ever contacted, it
wasn't done by me. Postel was contacted about assigning OIDs to whatever MIME
types are registered, which I don't believe he had any major objections to
doing.

> Either or both of these may be fabrication.

Both are nonsense, period.

				Ned