>> 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] > 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?&q=slavitch%20IETF
On 9/5/07, Michael Slavitch < [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
> >
> >
>
>
> --
> 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
