I'm astonished, but I actually agree with Lemon on this one.

 

HTTP was largely invented by a single guy, Tim Berners-Lee, by improving
upon the best ideas from previous systems *without attempting to be
compatible*.  He also wrote the first browser and server, and the first
websites.  He also founded the W3C.

 

Tim published his HTTP spec in 1991.  Mosiac came out in 1994.  Internet
Explorer in 1995.

 

It wasn't until 1996 - five years *after* the web was already born, and well
after it was mainstream - until the IETF got around to standardizing HTTP
1.0.

 

If anything, HTTP is the prime example of how implementation must *lead*
standardization, and that the IETF shouldn't bother trying to invent by
committee, but rather find and standardize the best of the existing
solutions.

 

-david

 

  _____  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lemon Obrien
Sent: Thursday, September 20, 2007 4:58 PM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] Best NAT traversal options

 

>> but HTTP enabled the vast majority of what we call the Internet.

 

text over tcp? it's the browser that built the internet, they just used http
cause that's

what the first browser was written to render. Ever since, they've
continually tacked on different kinds of crap to make it perform better;
anyone remember the "tag" wars between microsoft and netscape; look who won.
in fact, microsoft thrawts, changes, impeds, rolls-it's-own, standards all
the time to keep developers in line.

 

don't get hung up on standards.

Adam Fisk <[EMAIL PROTECTED]> wrote:

All valid points, Kerry.  I want to be clear, though, that I'm not arguing
the IETF protocols are technically superior to homespun solutions.  In some
cases they are, in some cases not.  I also agree they typically take more
time to implement, often significantly more when, as you say, you have to
pull in another 100 RFCs to get the functionality you want. 

I am convinced, though, of the power of interoperability.  I go back to HTTP
all the time and have pretty much beaten that argument to a pulp, but HTTP
enabled the vast majority of what we call the Internet.  It's certainly not
the most technically dazzling protocol out there, but the fact that it's a
standard allowed everyone to talk to each other and for everyone to build
creative services on top of it. 

I really think the reason we haven't seen a similar flourishing around some
of the newer protocols is that they're still too new and not as well
understood.  As the web continues to mature, I expect the need to
standardize on some way of doing a bunch of these things (NAT traversal,
media exchanges, etc) to grow more apparent. 

Heck, I could be wrong, but that's my reading.

-Adam



On 9/12/07, Kerry Bonin <[EMAIL PROTECTED]  <mailto:[EMAIL PROTECTED]> >
wrote: 

Thought I'd toss in my two cents on IETF vs. what most of us are doing,
since I deal with standards all the time, and regularly interact with some
well funded research groups that play in the same space.

IMHO one of the ways in which the IETF protocols are far less interesting in
practice is their desire to use many standard protocols together as the
'correct solution' instead of stepping on each others turf and trying to
combine them.  As listed below - STUN + ICE + SIP + ...  Add the complexity
and ambiguity of the specifications, lack of quality, unencumbered reference
implementations, and contrast it with the elegance possible if you simply
learn from these protocols and assemble your own that borrows the best of
each.

I faced this same dilemma when building my current transport protocol engine
- I needed DOS resistance (client puzzles) right up front, ECDSA with one
and two way cert exchange, session key management, encryption + MAC, all
over UDP with parallel virtual channels with different delivery options per
channel ranging from unguaranteed to ordered/guaranteed and with delivery
notification options.  Add NAT management on top (STUN, relays, ect.)

Do you know how many IETF protocols I would had to bolt together to get most
of that feature set, and how big and complicated the resulting codebase
would be?  And a simple requirement like client puzzles up front breaks most
standards, in any case, as does a simple requirement to operate over a
single random port number.

This is one of the biggest reasons why most of us roll our own.  The IETF
groups are performing great research in their niches, but the protocols
themselves are rarely useful outside of their testbeds.  On the other hand,
they make great reference reading, to see what use cases and solutions the
researches have documented, especially when those use cases match data we've
collected from the field.

Kerry Bonin


David Barrett wrote: 



I disagree with Michael's assessment of the motivation of IETF participants;
everybody I've met appears to have the best of intentions.

 

My concern is the real world always seems like an unwelcome guest in IETF
discussions, and I constantly feel like an ass for harping on things like
data, implementations, actual use cases, etc.

 

Regardless, I'm eager to hear your (forgive me) real-world results
implementing the IETF P2P stack (STUN/ICE/SIP/etc).  The proof is in the
pudding, so let's eat!

 

-david 

 


  _____  


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Fisk
Sent: Wednesday, September 12, 2007 10:11 AM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] Best NAT traversal options

 

Right.  I forgot I'd seen you over on some of those lists.  I'm surprised
you participate if you think it's all about commoditizing the competition or
gumming things up, though.  Which one are you doing?  Joking joking. 

No, I agree the IETF has problems, but some standard emerging out of the p2p
hackers list sure would scare me a lot more!

-Adam

On 9/5/07, Michael Slavitch <[EMAIL PROTECTED]> wrote:

For those that need help with that, try this:

http://www.google.com/search?
<http://www.google.com/search?&q=slavitch%20IETF> &q=slavitch%20IETF

On 9/5/07, Michael Slavitch < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> wrote:
> Yes, I know about the IETF.   Google is your friend.
>
>
> On 9/5/07, Adam Fisk <[EMAIL PROTECTED]> wrote:
>
> > Do you know many people who work in or with the IETF?  Have you worked
with
> > the IETF?  I'm sincerely asking, because I would be surprised if you had
and
> > continued to hold your views.  They make decisions by "taking a hum" for

> > Christ's sake -- similar the yeahs and the neighs (sp?).  These people
are
> > the enemy?  To me, it's a miraculous example of cooperation amongst
> > frequently competing interests. 
> >
> > -Adam
> >
> >
> >
> > On 9/5/07, Michael Slavitch <[EMAIL PROTECTED]> wrote:
> > >
> > > "The IETF is really not so different from this list -- a bunch of 
> > > people getting together to make stuff work."
> > >
> > > Not so sure about that.
> > >
> > > The goal of participating in a standards body to either make things 
> > > work to commoditize the competition or gum things up so that they
> > > never work,  are horrendoes to implement, thereby creating barriers to
> > > entry that only you can exploit. 
> > >
> > > Look at IMS, for example.
> > >
> > > How easy is it to get ICE working, and I mean >working<, not
"working".
> > >
> > > How long has it taken to develop and finalize? 
> > > _______________________________________________
> > > p2p-hackers mailing list
> > > [email protected]
> > > 
> > http://lists.zooko.com/mailman/listinfo/p2p-hackers
> > >
> >
> >
> > _______________________________________________ 
> > p2p-hackers mailing list
> > [email protected]
> > http://lists.zooko.com/mailman/listinfo/p2p-hackers
<http://lists.zooko.com/mailman/listinfo/p2p-hackers> 
> >
> >
>
>
> --
> Michael Slavitch
> Ottawa Ontario Canada
>


--
Michael Slavitch
Ottawa Ontario Canada
_______________________________________________ 
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers 

 






  _____  



  _______________________________________________


p2p-hackers mailing list


[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers    

 


_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers


_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers




You don't get no juice unless you squeeze
Lemon Obrien, the Third.

http://www.tamago.us

_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers

Reply via email to