Re: Content-MD5

> >As I said before, the IETF generally doesn't standardize two different
> >ways to do the same thing.

> There are enough exceptions -- OSPF/whatever-it-is,

While this is not my area of expertise, I nevertheless don't think it is an
exception -- there are simply a variety of different technologies providing
different services. I don't think any single technical niche is filled by two
different protocols that don't provide any other service.

> usenet/email,

First of all, UUCP mail formats are NOT standardized by the IETF. RFCs
describing such formats are strictly informational in scope.  As far as I know
they are not standardized by anybody -- if they are I'd love to know who is
doing it because I have a lot of compliants to make...

NEWS is another matter -- it absolutely supports my position here and not
yours.

NEWS is a different service from email in several significant ways, but they
are nevertheless both built on top of RFC822, and considerable effort has been
and is being expended to make sure that semantically identical services are
presented using the same syntax everywhere. In fact some of us were asleep at
the switch and let some inconsistencies arise. This will be corrected on the
email side, even when it takes a recycle at proposed to accomplish it.

There are also work items to standardize the use of MIME in News, rather than
use something different.

> pre-snmp/pre-whatever-it-was,

I do not believe what came before SNMP (HEMS/RFC1076?) ever made it onto the
standards track. In fact I believe it was abandoned in favor of SNMP so as not
to have two different standards track management services. (I don't think the
people behind it were very happy about this either.)

In any case, I haven't noticed any documents detailing the advancement of an
alternative management protocol in the past 4-5 years. Have you?

> character sets, 

The IETF doesn't standardize character sets, period. It follows that there
cannot be creation, let alone, duplication, of effort in this area.

> -- that I am glad you picked
> the word generally.  I'll claim you left enough open space by using that
> word that you did not say I am wrong and therefore while it may be
> an exception, it is possible.

Sure, anything is possible. Quantum mechanics allows for water to run uphill,
but I've never seen it happen...

> > I could go on and on, but suffice it to say that objections to protocols on
> > the basis of duplication of function are taken very, very seriously, and
> > such objections are going to be made should an attempt be made to standardize
> > some alternative to content-md5 without a clear understanding of how it
> > interacts with content-md5. I will object myself in my capacity as a member
> > of the Applications Area Directorate if it comes down to it.

> Fine.  Glad I can count on your vote. :(.  When it comes time to use SHA
> or some other hash -- or multiple hashes -- you will vote against a single
> combined header rather and would rather have two headers.  I think that
> is being stupid, but I will not write 2K of text trying to convince you
> otherwise.  In fact, I hope to write no more after this note.

First of all, I never said I would oppose the creation of a new digest field
that replaces content-md5. It would depend on what that proposal advocated and
why. All I said was that I would oppose having different schemes for HTTP and
email. And I will indeed oppose this.

In other words, you don't care enough to bother to try and reconcile the
two different schemes. That's fine with me, but surely you see it is this
sort of attitude that has led to the present situation?

				Ned

Received on Sunday, 5 November 1995 17:26:22 UTC