Some comments on standards, et cetera
- I'm in the process of writing up a paper on some of the things I talk about
below, and some that I don't. This mail is just to throw out what I think to
be the most preferable course of action w/r/t standards, interoperability,
and the role of consensus, politics, et cetera in that realm.
For the record, I simultaneously agree with a number of conflicting points
on the issue of standards. For one, I do see them as premature optimization,
as Clay said, in a lot of cases. One of the worrying things about standards
in software and in computing in general is that there are so many of them.
Therefore, I don't think we should be rushing, as a whole, towards
I think that standardization naturally comes about when there is a
prevalence of things being done differently that are fundamentally alike by
a number of different implementations. Premature standardization seems to be
a tactic used by companies looking to get their particular method of doing
something become adopted. I can cite a number of examples in the software
realm towards this, but I don't necessarily think they're germane because
they also usually hinge on completely different base technologies that a
given company has an investment in (for instance, EJB and COM are both
"standards", and attempt to solve the general problem of objects as
components, but both are slaves, at least somewhat, to their implementation
technologies, and hence, the companies that spawned them).
Community developed standards usually come later. This is not to say that
community developed standards are always "best" (for differing values of
"best"), but the process is usually much healthier. The oft-cited example of
the IETF working groups is in this vein, and I think it still holds water.
Indeed, the APEX WG is some evidence of this. And I'm following the new
developments within the Intel WG with cautious interest. I think there was a
massive loss of faith at the first WG meet in that particular institution
and that has sort of bled out into a distrust of anyone promoting standards
and WGs in the P2P space at large. I think _that_ reaction is an
over-reaction, and a bit shortsighted.
Interoperability, to me, is based upon the principle of agreement. A
standard is not a pre-requisite for interoperability, but is usually the
artifact of a standing agreement. Many standards are nothing but the Magna
Carta of a long standing agreement that allows other people to become
interoperable (or in some cases, forces them to) because of their internal
process. I think we all know well the case of not being able to implement
something well suited to a given task because it wasn't a standard or
Needless to say, the two concepts are very related, but I don't think having
one will necessarily give you the other.
I'm an open advocate of consensus (as my last few mails have undoubtedly
made clear) because I believe that consensus is a process for group
agreement. The tools of consensus are common goals and informed debate.
Consensus works best in an open environment. I'm promoting consensus on the
list because I think it allows us to explore all those roads we might not go
down due to early standardization but helps us get over those roadblocks of
non-interoperable implementations. It's not a solution in and of itself but
rather a way to map the length, width, and depth of the emerging space
before us without getting lost and unable to find each other.
I'll shut up about this now.
Dan Moniz <dnm@...> [http://www.pobox.com/~dnm/%5d
- On Tue, Feb 20, 2001 at 05:41:50AM -0000, allenjs@... wrote:
> I am having trouble understanding exactly what this "guarantee" ofProbably true. *grin* And it's not a matter of 'running out'
> document identity is going to accomplish in real-world terms? SHA1 I
> think everyone has agreed will not be likely to run out of good IDs
> for a decade or so. But we are talking probabilities anyway -- isn't
> it more likely that some electromagnetic discharge caused by you
> rubbing your socks on the carpet will flip the bit in your computer
> that tests (duplicate==true) than that SHA1 will have dups?
of good IDs, it's a matter of the probability of a collision.
> And then when we start talking about unique identifiers for everyWell, a URL uniquely identifies a document. It isn't so good at
> document, file, etc. that ever exists, exactly what is the point? If
> you have 99gigaboozillion documents all sitting in the same context,
> you have much bigger problems than duplicate collisions.
determining whether two documents are the same though.
> I hear the discussion about SHA-1 and I am having trouble figuringIt is possible to have a naming scheme that guarantees a unique
> out what problem you are exactly trying to solve? No hash will ever
> solve a problem except to a "good enough" degree, so the problem
> definition should determine what "good enough" is. For example, I
> once proved that using the first 4 bytes of MD5 was sufficient to get
> a hash that was unique for every word in the english language. SHA-1
> will never be "perfect" anyway, so maybe it doesn't even make sense to
> use the whole hash?
name. That is very difficult to manage across seperate P2P networks
though. For the purposes of identifying documents that are the same
document from different P2P networks, SHA-1 is the best proposal I've
seen so far.
I'm arguing because it's significantly easier, within a single
P2P network, to build a naming scheme that assigns unique names than it
is to build a personal meteorite defense shield, even if you're more
likely to need the latter. I'll stop now though because I don't have a
better answer for naming across P2P networks.
Have fun (if at all possible),
The best we can hope for concerning the people at large is that they
be properly armed. -- Alexander Hamilton
-- Eric Hopper (hopper@... http://www.omnifarious.org/~hopper) --