W3C home > Mailing lists > Public > ietf-discuss@w3.org > June 2000

Re: Only include implemented features in a draft standard

From: Keith Moore <moore@cs.utk.edu>
Date: Thu, 15 Jun 2000 19:15:26 -0400
Message-Id: <200006152315.TAA27813@astro.cs.utk.edu>
To: Jacob Palme <jpalme@dsv.su.se>
cc: IETF Applications Area Discussion List <discuss@apps.ietf.org>
> At 08.05 -0400 0-06-15, Keith Moore wrote:
> >> If you did not check this, how can then the
> >> standard include a paragraph like the one quoted above,
> >> since the statement requires any level of multipart nesting,
> >> but since this has not been interoperability tested?
> >
> > you appear to be confusing interoperability tests with conformance or
> > stress tests. conformance / stress tests can sometimes be useful but
> > we're not required to do them in order to advance a document.
> I do not understand this. If a system is designed so that
> it cannot produce deep levels of multipart nestings, then
> no interoperability can be demonstrated for such nestings.

depends on what you mean by 'system'.  if a particular MIME
client cannot produce deep levels of nesting, that's not 
an issue with MIME as a whole because (a) MIME is perfectly capable
of representing deep levels of nesting, (b) there do exist MIME
generators that can generate deeply nested messages, and (c) there
also exist MIME readers that can handle deep levels of nesting.

given the above, it's difficult to see how the MIME spec is flawed,
since we have adequate evidence that folks can do deep nesting with
MIME if they want to.  the purpose of the interoperability tests
are to debug the spec, and in this case, the spec seems sufficiently
clear as to how to implement multipart nesting.

> This is then, obviously, an interoperability and not a
> stress issue.

no.  your premise is false, and your conclusion doesn't follow.  

> So the statements in the MIME standard that ANY level of
> multipart nesting should be supported is *not* supported by
> *interoperability* tests.

true.  but such statements are not required to be supported by
interoperability tests, any more than we require interoperability
tests to determine whether (say) an SMTP implementation can
handle command lines or email addresses of the maximum allowable

>  Should such a statement then be
> in a DRAFT STANDARD, if IETF requires that a DRAFT STANDARD
> should only describes features which work in
> *interoperability* tests?

nesting of multiparts is a feature, and it has been tested and known
to work.   but the degree to which nesting works is an implementation
characteristic (it's not a characteristic of the spec) and we're not 
required to test for such things.

the purpose of interoperability testing is to debug the specs - to
make sure that they are clear enough to allow implementations to

> > there are certainly MIME implementations that can produce more than
> > 4 levels of multipart nestings, and there are MIME implementations
> > that can parse more than 4 levels of multipart nestings.
> >
> > p.s. I'm a bit puzzled by your choice of this particular issue.
> Sorry, maybe my example was not well chosen. It chose this
> example because it is such a basic feature of MIME, which I
> believe everyone agrees should be there, that you should
> support multipart nesting to any level. But maybe my
> example was wrong, in that there actually are two
> independent implmentations which can produce arbitrarily
> deep nestings.

I suspect that any mime implementation is limited in practice to
some level of nesting.   (whether sender or receiver)  just because
memory, disk, etc. are finite resources.

> The reason I am raising these issues is the issue of whether
> we should start a process of moving the MHTML standard from
> proposed to draft. The testings made by two students show
> that all the systems tested were only able to produce some
> very simple combinations of use of MHTML, and that no system
> was able to generate more complex combinations. And what I
> am wondering if is this should mean that we should change
> the MHTML standard, when moving to draft, by describing the
> simple combinations which systems actually do generate, and
> say that the standard only applies to these simple combina-
> tions. For example, the students found that systems are able
> to receive and generate Content-Location, and are able to
> receive and generate Multipart/alternative with HTML in one
> branch and plain text in the other branch. But no two systems
> seems to be able to receive and generate a combination of
> these two features. Does this mean that we should write in
> the standard that Multipart/alternative and Content-
> Location cannot be combined? Or that we should wait with
> moving MHTML to draft until there are two interoperable
> systems which can handle this combination?

again, the purpose is to debug the spec.  if the spec is unclear,
or if it asks too much of implementations, that's a problem that
needs to be fixed.  

senders and receivers are a bit different - a sender may have specific needs
and therefore might not implement all features of MHTML - it's perfectly
reasonable for a sender to only implement the features it needs.
a receiver might need to implement more features.

if you've found that the spec isn't clear enough regarding what MHTML
features have to be implemented by a receiver, then this should be clarified.

if you've found that the spec isn't clear enough about how to generate
certain kinds of MHTML constructs, then this should be clarified.

if you've found that the spec documents features that nobody seems to have
a use for in practice, then those features should probably be removed.

if you've found that certain combinations of features don't work on
>= 2 receivers, then the progression of MHTML should be delayed until
there are enough implementations that do, or the spec should be edited
so that it's requirements aren't too onerous.

but if you've only found that senders don't seem to want to use certain
combinations of features (i.e. they don't want to combine them in 
arbitrary ways), I don't see that as a problem, as long as receivers can
deal with all of the features (in whatever combination)
in the messages that they receive.

Received on Thursday, 15 June 2000 19:17:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:08 UTC