Loading ...
Sorry, an error occurred while loading the content.

Some comments on standards, et cetera

Expand Messages
  • Dan Moniz
    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
    Message 1 of 38 , Feb 18, 2001
    • 0 Attachment
      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
      standardization.

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

      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
    • Eric M. Hopper
      ... Probably true. *grin* And it s not a matter of running out of good IDs, it s a matter of the probability of a collision. ... Well, a URL uniquely
      Message 38 of 38 , Feb 20, 2001
      • 0 Attachment
        On Tue, Feb 20, 2001 at 05:41:50AM -0000, allenjs@... wrote:
        > I am having trouble understanding exactly what this "guarantee" of
        > 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?

        Probably true. *grin* And it's not a matter of 'running out'
        of good IDs, it's a matter of the probability of a collision.

        > And then when we start talking about unique identifiers for every
        > 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.

        Well, a URL uniquely identifies a document. It isn't so good at
        determining whether two documents are the same though.

        > I hear the discussion about SHA-1 and I am having trouble figuring
        > 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?

        It is possible to have a naming scheme that guarantees a unique
        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) --
      Your message has been successfully submitted and would be delivered to recipients shortly.