Slashdot Mirror

QuickTime Streaming is based on the IETF standard RTSP and RTP protocols. Go here and here to download the specifications yourself.

AFAIK, you're right about RealSystem and Windows Media though.

QuickTime Streaming is based on the IETF standard RTSP and RTP protocols. Go here and here to download the specifications yourself.

AFAIK, you're right about RealSystem and Windows Media though.

A mess: that's what I think the whole DNS system has become. It is being used for something which is completely unrelated to what it was designed for: it was designed as a way to associate IP addresses to computer names, and it is being used as a way to find data on the information web.

The three-letter domains are not at all being used as they should. Essentially, any name of importance gets registered under .com, .org and .net (except, of course, just the name I happen to be looking for, which is registered in just the one I don't think it is).

Now even two-letter domains are being used stupidly. We already have the .jump.to and .go.to silliness (.to is the country of Togo), now for the .tv silliness.

The solution lies, I think, in developping a new distributed database (one that is truly distributed and not centralized-distributed as the DNS is) and to replace Uniform Resource Locators by the Uniform Resource Names defined in RFC 2141 (not implemented) subset of Uniform Resource Identifiers.

It is certainly worthwhile to pursue research in this direction, if only to gain insight on how distributed databases can work. Unfortunately, it will be many years before a solution can be practically implemented, even if one is found. I am afraid that organizations such as the IETF are gradually being contaminated by commercial near-sightedness. But then, IPv6 development has been possible, even though it was a long-term project, so maybe a DNS replacement is not all that hopeless.

For the remote hosts, we need protocols that do not allocate resources unless they are absolutely necessary. Look at upcoming protocols like SCTP. The protocol mandates that the initial connection sequence be stateless on the server side. So at levels below the application, DDoS attacks become much, much harder. This is essentially the SYN cookie hack, but made official.

So what about the application level? Well, applications need written to allocate state only when absolutely necessary. This doesn't necessarily imply pushing all state to the client side, however. Mainframe folks have been doing some this for a long time. It'd be interesting to see just how much carries over to a networked system.

And NI / bus bandwidth on the receiving host? This one's a cool problem. How much processing can be done in the NI to reduce host bus traffic? And how can one reserve resources in the NI to statistically guarantee that proper sessions work during a bombardment with bogus sessions? (Extra credit: How does one move some of the app-level down to the NI to help? Or out to the routers?)

These are the interesting areas for server-side DoS defenses, not DNS and router games. Then things like CIDF and/or the idwg work for detecting and squelching DDoS attacks... Imagine if every Gnutella, SETI@home, and distributed.net client and server also helped with DDoS detection... Much more interesting and practical than DNS and router tricks.

And then there's the boost in performance SETI and distributed.net would get from the new IMPS protocol...

For the remote hosts, we need protocols that do not allocate resources unless they are absolutely necessary. Look at upcoming protocols like SCTP. The protocol mandates that the initial connection sequence be stateless on the server side. So at levels below the application, DDoS attacks become much, much harder. This is essentially the SYN cookie hack, but made official.

So what about the application level? Well, applications need written to allocate state only when absolutely necessary. This doesn't necessarily imply pushing all state to the client side, however. Mainframe folks have been doing some this for a long time. It'd be interesting to see just how much carries over to a networked system.

And NI / bus bandwidth on the receiving host? This one's a cool problem. How much processing can be done in the NI to reduce host bus traffic? And how can one reserve resources in the NI to statistically guarantee that proper sessions work during a bombardment with bogus sessions? (Extra credit: How does one move some of the app-level down to the NI to help? Or out to the routers?)

These are the interesting areas for server-side DoS defenses, not DNS and router games. Then things like CIDF and/or the idwg work for detecting and squelching DDoS attacks... Imagine if every Gnutella, SETI@home, and distributed.net client and server also helped with DDoS detection... Much more interesting and practical than DNS and router tricks.

And then there's the boost in performance SETI and distributed.net would get from the new IMPS protocol...

IPv4, in general, has already been extended like crazy... why not just work towards developing and migrating to IPv6 instead?

The original BUGTRAQ post is here. Taken from the post, the summary reads:

HTTP cache-control headers such as If-Modified-Since allow servers to track individual users in a manner similar to cookies, but with less constraints. This is a problem for user privacy against which browsers currently provide little protection.

Essentially, instead of giving you a cookie (which many people refuse/block) they give you a unique "cache freshness" timestamp, which your broswer nominally sends back with the conditional-GET request [see the HTTP RFC esp. sections 9.3 and 13.3.3 for description].

Note that the site would have to use the same thing linked from every page to track you, e.g. a 1x1 transparent gif. Also note that this becomes pretty useless for them if you block the REFERER header, which you should be doing any.

If this kind of thing bothers you, you should be using the Internet Junkbuster anyway.

--

• Computers
• Networks
• Medicine
• Business
• Law
• Government
• War
• Everything Else

>Snail mail? Heck, you could even use carrier >pigeons.

RFC1149

RFC1149
Pretty funny! I seem to remember there was one of these for a coffee pot protocol... hmm...

And here is what IETF is discussing now: http://www. ietf.org/internet-drafts/draft-polk-slp-loc-auth-s erver-00.txt. It is a draft of RFC to deal with the geographic location of an IP device. The asbtract is here:

Since the JPEG uses lossy compression, digital watermarking and steganography do not work very well with that format. The preferred formats are GIF and BMP. Also, digital watermarking does not preserve the information across file format conversions. Given this, how useful is the copyright that is normally watermarked when it could be removed through file format conversions (GIF->JPEG->GIF) by anybody, including intelligent monkeys? Does anybody else remember when this used to be called covert channels?

I agree ... Coopers is the stuff, especially Dark Ale on tap ! Look who else is coming to visit Australia (Adelaide in fact - the home of Coopers) http://www.ietf.org/meetings/IETF-47.html Obviously the ietf know their beer :-)

As the other poster who replied said, you're making assumptions: "The Net is nothing but the Web, and the Web is nothing but companies."

A proper URN system will do this properly. Maybe for US people typing in "McDonalds" alone will find the fast food chain, but maybe in the UK it will prompt so you can choose the family group (clan?) instead. A proper system will have to avoid simply creating another monopoly space where only big businesses show up.

By the way, the IETF URN Working Group might help explain some of the issues.

ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here.

It seems that .org indicating a non-profit site is slightly inaccurate perception that has developed. One that loses relevance if browsers can perform searches from the URL Address.

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

$1,000 US ICANN application fee

$5,000 US ICANN annual fee

$70,000 US in working capital

not to mention...

$10,000 US NSI registration fee

$100,000 US performance assurance bond

and even after all that trouble, NSI will take $9 US from every registration I were to put through! It's nice to have a say in who gets to go through, and to perhaps bring NSI back down to earth.

This has brought my conclusion to going through the Tucows OpenSRS system, which is a free registration and free perl based CGI's, through which I can register domains for a simple $10 US per year ($9 of which goes to NSI, $1 going to Tucows for providing us with this great service).

Some more links for those of you ready to become your own registrar:

http://www.iana.org/

http://www.icann.org/

http://www.ietf.org/

http://www.nsiregistry.com/

http://www.internic.net/

Good luck! I hope everyone helps contribute to the OpenSRS project, as it will certainly be the way of the future for small ISP's like myself who can't afford NSI's outrageous costs and bonds.

- EraseMe

Is this really is the very inventor of SRP, Thomas Wu, speaking? Assuming that it is, welcome to the party! I'll make the same plea I made in email to you 2 years ago - splash this news all over the web page! I think the world will take SRP far more seriously if you will put that in writing and avoid ambiguity. E.g. can people sell their own SRP implementations without a license? Without a fee?. The appropriate way to do so is to write a letter to the IETF along the lines of

http://www.ietf.org/ipr.html

It will need to be in legal language. In my experience, IETF won't be interested in putting it on the standards track unless it uses the model of the SSL patent from Netscape: free for *all* uses (not just open-source or non-commercial), reserving only the right to use it defensively, i.e. preventing other companies from going after you for infringing patents on SRP-related stuff that they may assert. E.g.: from RFC2246 on TLS (the successor to SSL):

Netscape Communications has issued the following statement:

Intellectual Property Rights Secure Sockets Layer

The United States Patent and Trademark Office ("the PTO") recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to Netscape for inventions described as Secure Sockets Layers ("SSL"). The IETF is currently considering adopting SSL as a transport protocol with security features. Netscape encourages the royalty-free adoption and use of the SSL protocol upon the following terms and conditions:

• If you already have a valid SSL Ref license today which includes source code from Netscape, an additional patent license under the SSL patent is not required.
• If you don't have an SSL Ref license, you may have a royalty free license to build implementations covered by the SSL Patent Claims or the IETF TLS specification provided that you do not to assert any patent rights against Netscape or other companies for the implementation of SSL or the IETF TLS recommendation.

What are "Patent Claims":

Patent claims are claims in an issued foreign or domestic patent that: 1) must be infringed in order to implement methods or build products according to the IETF TLS specification; or 2) patent claims which require the elements of the SSL patent claims and/or their equivalents to be infringed.

--Neal

Surely it's in your interest as an ISP to block traffic from your customers that has spoofed source addresses. These DoS attacks use a lot of bandwidth, so they degrade your service too.

The IETF thinks so: RFC2267 on "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" just got approved as "Best Current Practice" which means ISPs are strongly advised to do it.

look it up in RFC1149 - D. Waitzman, "A Standard for the Transmission of IP Datagrams on Avian Carriers"

troll, ...They lived in mountains, sometimes stole human maidens, and could transform themselves and prophesy...

... could anyone (previous poster even) dig up a link to a page which explains how OSS created the internet?

Hmmm. I don't think I have a link that says, specifically, "OSS created the Internet". For starters, the term "Open Source Software" hadn't been coined yet. Besides, assertions are worthless alone; it is the proof that backs them up.

So take a look at the Internet Engineering Task Force and this archive of Internet Requests for Comments (RFCs). You will find the Internet was developed through the same process of open development, code sharing, and peer review that define OSS software development. Everything you use on the web today, from the Domain Name System to the Simple Mail Transfer Protocol to HTTP itself was developed using OSS principles. "We believe in rough consensus and working code", to quote David Clark of the IETF. That seems to define OSS pretty well.

I thought Al Gore did that.

Cute. :)

The BeOS would never have been developed if it was open source.

See above about assertions without proof.

The sheer slickness of it is testament to how much close planning and discussion went into its design.

OSS and planning and discussion are not mutually exclusive. Indeed, discussion is one of the key tenets of OSS. OSS projects are often characterized by the intense, often heated discussions that take place on their mailing lists. It may be a process of beating it into shape rather then careful artistic planning, but the end result seems to be the same. One man's hammer is another man's paint brush, so to speak.

The business model, in Be's case at least, can work very well for developing high-quality products...

Certainly; BeOS itself is evidence of that. I was never arguing against BeOS. However, the fact that closed development can work does not mean that open development cannot.

... because of the fact that each programmer is working in sync with everyone else.

Again, that happens in OSS as well. True, as you note, you often find different people and projects overlapping. However, this is not necessarily a Bad Thing. For one, it offers a form of redundant protection against failure. Second, it fosters an almost Darwinian approach to software development. Many ideas are put forward, and the best selected.

Look at Gnome and KDE. Two projects aiming to accomplish the same thing, and thousands of hours of work wasted.

Interesting. When two companies compete against each other, that competition is generally viewed as a Good Thing (here in the USA, anyway). No one (other then socialists (no, I'm not calling you a socialist (nor am I offering opinions on socialism in general, one way or the other))) calls that competition "a waste". Why should it be any different for OSS development? The GNOME and KDE projects are both offering different solutions to the same problem. Cooperation between the two is quite good, so compatibility should be high. The end result is more choice and better software, as the good ideas live on and the bad ones die off. I don't regard that as a waste at all.

The fact is that the BeOS is a more technically sophisticated, better designed OS that Linux, and it is thanks to closed source design that it has gotten this far.

Ohhhh, inflammatory and unsupported in the same sentence! Did you do that on purpose? :-)

Anyway, BeOS and Linux each have their strengths and weaknesses. You don't put forward any arguments for either of your points: BeOS "better designed" then Linux or that closed development has gotten BeOS this far. I could as easily say that "BeOS would be much further along if it was OSS", but I don't. Please add some justification for your argument, or stop cluttering up the discussion. Thank you. :)

Also check out the article in the MS knowledge base "Wind ows 95/98 DHCP Client Modified for RFC2131 Retransmission Compliance" which states that "This issue can occur because the DHCP client-retry mechanism in Windows 95 and Windows 98 is not in compliance with RFC 2131."

They finally fixed it in Windows 98 Second Edition. NT is ok. Not that I want to bash MS or anything, I just hate to see them get credit for developing an open standard when they don't even comply with it themselves.

The concept is called "protocol encapsulation." As in H.323 videoconferencing protocol over HTTP. Since we also must do videoconferencing with our customers, we need a configuration that works over the Internet as well as the LAN, and our firewalls are configured such that HTTP is the viable solution.

As for file transfers, HTTP-DAV is nice because it allows totally clueless end-users to post documents via the web browser, rather than use some other application to handle file transfer. Since they are already using the browser as the interface for just about everything else, allowing them to post documents via the browser reduces end-user training requirements.

I'm not certain what you mean by using protocols that actually suit what I'm doing, as these two protocols (H.323, HTTP-DAV) are being used exactly as the designers intended.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The Internet Engineering Task Force (http://www.ietf.org) is working on an instant messaging standard, known as IMPP (Instant Messaging and Presence Protocol). The Working Group has a few Internet-Drafts available at http://www.ietf.org/html.charte rs/impp-charter.html, but no RFCs yet.

My impression is that the design of this protocol (in opposite to e.g. ICQ) is good, and I think this will be _the_ IM protocol to use, when IETF's work is finished. AFAIK, at least Microsoft is going to use IMPP (this is the "open standard" referred to during the IM war with AOL).

The Internet Engineering Task Force (http://www.ietf.org) is working on an instant messaging standard, known as IMPP (Instant Messaging and Presence Protocol). The Working Group has a few Internet-Drafts available at http://www.ietf.org/html.charte rs/impp-charter.html, but no RFCs yet.

My impression is that the design of this protocol (in opposite to e.g. ICQ) is good, and I think this will be _the_ IM protocol to use, when IETF's work is finished. AFAIK, at least Microsoft is going to use IMPP (this is the "open standard" referred to during the IM war with AOL).

What you described is what the IETF and the RFC mechanism is for.

In fact, they already have a
working group on the Instant Messaging and Presence Protocol (impp)

What's really needed is one basic, open, interoperable standard. Think of email. Every ISP runs an SMTP server for their customers, and any ISP can email any other ISP's customers. The network is set up so that individual nodes can figure out where things go by MX records and other standardized mechanisms.

We need something like that for IM.

Since there is no financial incentive to allow your competitors to access your servers (and you customers), it seems to me that the only way around this is a global service run on a not for profit basis, that allows _anyone_ to use it with any client they like (ie, open the message protocols to the public).

NO NO NO! First of all, if there were "no financial incentive to let competitors access your servers", there would be no such thing as email.

Do you remember how back in the eighties, there were all these proprietary email services, and you could only send somebody a message if you were on the same service as them? Remember Compuserve, MCIMail, ATTMail, Fidonet, and then there were those internet people in the universtities.

Ever heard of Metcalfe's law? Bob Metcalfe, the former CEO of 3COM and inventor of "Ethernet" networking technology is credited with this idea, commonly referred to as Metcalfe's Law:

(Paraphrased) The power of a network increases exponentially with each additional node...

That's why it made sense for everybody to drop the proprietary email protocols, and use the open standard. That's why it's in everybody's interest to have one unified, decentralized, open IM protocol that everyone can use.

Secondly, this is NOT an area where governments belong.


-James

What you described is what the IETF and the RFC mechanism is for.

In fact, they already have a
working group on the Instant Messaging and Presence Protocol (impp)

What's really needed is one basic, open, interoperable standard. Think of email. Every ISP runs an SMTP server for their customers, and any ISP can email any other ISP's customers. The network is set up so that individual nodes can figure out where things go by MX records and other standardized mechanisms.

We need something like that for IM.

Since there is no financial incentive to allow your competitors to access your servers (and you customers), it seems to me that the only way around this is a global service run on a not for profit basis, that allows _anyone_ to use it with any client they like (ie, open the message protocols to the public).

NO NO NO! First of all, if there were "no financial incentive to let competitors access your servers", there would be no such thing as email.

Do you remember how back in the eighties, there were all these proprietary email services, and you could only send somebody a message if you were on the same service as them? Remember Compuserve, MCIMail, ATTMail, Fidonet, and then there were those internet people in the universtities.

Ever heard of Metcalfe's law? Bob Metcalfe, the former CEO of 3COM and inventor of "Ethernet" networking technology is credited with this idea, commonly referred to as Metcalfe's Law:

(Paraphrased) The power of a network increases exponentially with each additional node...

That's why it made sense for everybody to drop the proprietary email protocols, and use the open standard. That's why it's in everybody's interest to have one unified, decentralized, open IM protocol that everyone can use.

Secondly, this is NOT an area where governments belong.


-James

IETF's IMPP Working group (charter) Maybe this was mentioned deeper in someones thread, but all the same i figured I would point out that there is a standard being developed. Last I heard the group was getting fairly close to having a spec.

The IETF has an Instant Message and Presence Protocol Working Group which is looking at this.

The IETF has an Instant Message and Presence Protocol Working Group which is looking at this.

The article refers to an IETF effort to pruce an instant messageing standard, if anyone is interested here is the url to it's chater page.

For anyone who hasn't been following this issue you have several different messageing programs all backed by one company or another which do not 'talk' to each other. An equivelenet would be if it was imposible to phone somone from your phone because there phone came from a different telco. The situation is completely stupid, all logic dictates that communications systems designed for the same purpose should be able to talk to each other.

AT&T are doing the right thing in the wrong way, inter operability should be a priority but not by some strange kludge that only works one way. Does anyone else agree that if this carries on for much longer it may be a job for legislation to bring the IM providers into line

One thing that really impressed me was the success of icq, I never really use it myself but a totaly centralized propriatry system being that big a success is not exactly the norm on the on interent.

• It'll not be scalable enough.

  For instance, there will need to be a "compression extension" because XML is verbose, thus making messages large.

• It'll not be robust enough.

  Thus requiring an extension so that messaging can be managed by MTS and/or MSMQ, or WTCTNY (Whatever They Call Them Next Year).

• It'll not integrate well enough with whatever tools they're using next year.

None of the technologies are inherently a problem:

• SOAP doesn't seem to be massively worse than XML-RPC although it's probably not as good as Casbah's LDO system.
• MTS is probably not as good as Encina or Tuxedo, but is doubtless better than the nonexistent TP monitors not being deployed in departmental/workgroup systems
• MSMQ may not be as good as Tuxedo, or as open as Isect, and is merely derivative of IBM MQSeries, but doesn't seem to be too bad, again being better than the asynchronous messaging systems nonexistent in non-big-iron systems

The implementations may be run-of-the-mill and derivative, but they're based on pretty good ideas, which is why it's been pretty easy for MSFT to market them.

What is a massive problem is that what gets deployed next year is liable to be massively incompatible with what is available this year.

In a sense, the only hope for developers that use the stuff is if there is some sort of "mass disconnect" where MSFT gets split into MSFT-1, MSFT-2, MSFT-3, ... and this results in the tools deployed having an extra year to stay vaguely stable...

But this was out on the IETF raven list a couple of weeks ago. ZDTV did go into some more detail, but William Allen Simpson first posted about it on November 18th, and followed up on November 19th.

But this was out on the IETF raven list a couple of weeks ago. ZDTV did go into some more detail, but William Allen Simpson first posted about it on November 18th, and followed up on November 19th.

• Between the KDE Two Conference material and KDE 2.0 Technology Overview, it appears that there is a proliferation of messaging systems.

  It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?

  What comes to mind are:

  • Lightweight Distributed Objects (LDO), submitted as an IETF draft, and
  • HTTP-SOAP, also an IETF draft
• Has any consideration been made of using some of the configuration libraries and data formats already available, such as:
  • ACAP, which has an IETF draft
  • libPropList which is used by GnuStep and OpenStep as well as by WindowMaker.
  • Ted Tso's .ini file reader?

It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.

• Between the KDE Two Conference material and KDE 2.0 Technology Overview, it appears that there is a proliferation of messaging systems.

  It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?

  What comes to mind are:

  • Lightweight Distributed Objects (LDO), submitted as an IETF draft, and
  • HTTP-SOAP, also an IETF draft
• Has any consideration been made of using some of the configuration libraries and data formats already available, such as:
  • ACAP, which has an IETF draft
  • libPropList which is used by GnuStep and OpenStep as well as by WindowMaker.
  • Ted Tso's .ini file reader?

It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.

• Between the KDE Two Conference material and KDE 2.0 Technology Overview, it appears that there is a proliferation of messaging systems.

  It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?

  What comes to mind are:

  • Lightweight Distributed Objects (LDO), submitted as an IETF draft, and
  • HTTP-SOAP, also an IETF draft
• Has any consideration been made of using some of the configuration libraries and data formats already available, such as:
  • ACAP, which has an IETF draft
  • libPropList which is used by GnuStep and OpenStep as well as by WindowMaker.
  • Ted Tso's .ini file reader?

It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.

The IETF is already doing this. They have an "Instant Messaging and Presence Protocol" Working group. Check it out.

Of course, they take a long time to get anything together, but standards engineering needs to be good.

-Ted

First you have to ask yourself - What does Mozilla 5 have working right now, what does IE 5.0 have right now? Let's see:

Mozilla 5 beta
HTML 4.0, CSS1, partial CSS2, XML (disp w/CSS), plugin support, Javascript, full DOM. No shortcut key for 'back' though.
There will be no support for XSL, XQL, SVG, WebDAV VML, or P3P support

Internet Explorer 5
HTML 4.0, partial CSS1, CSS2, XML, XSL, XQL, VML, HTCs - HTML behaviors, WebDAV, SMIL, plugin support, Javascript, full DOM

My opinion on what IE 5.5 release will add, based on what I have heard elsewhere:
Full CSS1/HTML 4 compatibility (always been a sore point with IE browsers, they're finally listening to the Mac people about standards)
SVG support
xHTML 1.0 support
HTML 4.01 support
P3P support
Dynamic shrinking of webpages (ala Opera)

Will they slow down? What are all those paid programmers supposed to do then? There's a lot of money and time invested into the browser, which is becoming the user interface of the next century. There's no way they're slowing down, unless they go broke first.

To those who go 'so what' about all these technologies, so be it. I refuse to be stuck in 1997 w/NS 4.x, or 1993 using Lynx. You can though - be my guest

"What would the image of the IETF be if we were to refuse to standardize any technology that supported wiretapping? In the Interne community? In the business community? To the national regulatory authorities?"

It is a tough balance act. I'm sure they want to simply refuse it if they can, but they understand it would be an irresiponsible thing to do. Don't scream from one side just reading the headline, and follow the Raven discussion if you care.

"What would the image of the IETF be if we were to refuse to standardize any technology that supported wiretapping? In the Interne community? In the business community? To the national regulatory authorities?"

It is a tough balance act. I'm sure they want to simply refuse it if they can, but they understand it would be an irresiponsible thing to do. Don't scream from one side just reading the headline, and follow the Raven discussion if you care.

Why Not Get Microsoft Where It Will Really Hurt

Convince the IETF http://www.ietf.org/ to require anyone who implements the latest HTML specs to Open-Source their browser software.

The HTML 4.0 specs exist as an open standard. Why not make any company that wishes to implement it have to open-source their software?

I'm not sure how to do this. Any ideas if it's feasible?

Plus (I'm on a Mac), does anyone know what Amaya (http://www.w3.org/Amaya/) is capable of doing? It runs on Linux-PC. Sounds like it is an HTML 4.0 compliant browser environment. Is it?

The network number is assigned by the network and is used to route the packet back to you, just as in IPv4.

See RFC2373: IP Version 6 Addressing Architecture as well as Privacy Extensions for Stateless Address Autoconfiguration in IPv6 for more details.