Slashdot Mirror

XLink, http://www.w3.org/XML/Linking/ one of the XML languages, was to have supported multiple links. Work has finished and now seems to be oriented and folded into XPointer.

List numbering is a presentation detail covered in CSS2 (which is being revised, and will be re-released as CSS2.1).

List numbering is a presentation detail covered in CSS2 (which is being revised, and will be re-released as CSS2.1).

Jakob Nielsen wrote about frames and iframes: "All of a sudden, you cannot bookmark the current page and return to it (the bookmark points to another version of the frameset), URLs stop working, and printouts become difficult."

The bookmark problem happens with POST-driven interfaces as well, such as many webmail apps. And how would one create Google Groups without frames?

"Even worse, the predictability of user actions goes out the door: who knows what information will appear where when you click on a link?"

If there are two frames side by side, one for a list of messages and one for the message, what's so unpredictable about that?

About the deprecation of <li value="...">: read this.

It irks me to see people taking a position to not use the W3C standards. You don't need to encourage that

Other than that XHTML 1.0 Transitional was the last W3C HTML standard to support semantic numbering of list items (the value element of the li element) or dynamic replacement of object contents on click (the target element of the a element), both of which were deprecated in XHTML 1.0 and removed from XHTML 1.0 Strict and XHTML 1.1?

Other than the inability to set proper XHTML media types through some web hosting providers, combined with a setup fee to switch hosting providers?

Other than Microsoft Internet Explorer's inability to read XHTML documents served with an XHTML media type without an obscure hack?

Other than the absence of a canonical default stylesheet for web authors to start from, making XHTML 2.0 complicated to get started with and discouraging look-and-feel consistency among web sites? In HTML 4, links are blue + underline because browsers have their own stylesheets for HTML, but no current browser understands XHTML 2 without an external stylesheet, and it appears to be each web author's job to duplicate effort in creating such a stylesheet.

Little inconveniences like this are why people stay on HTML 4 rather than one of the W3C's newer XML applications.

...and his page dosen't validate either....

Why didn't you just use an <object> tag?

I'll grant that XHTML 1.0 doesn't make clear either way whether its text/html compatibility profile extends to future versions, but will assume it does for a moment. So if you wish to use text/html, you must follow the guidelines of Appendix C of the XHTML 1.0 specification.

Another big one is use of the name attribute as a fragment identifier (C.8 in XHTML 1.0 spec). These are used for such things as anchors within a document. Again, 1.0 Appendix C has a suggestion that one set the id and name attributes together to the same value. And XHTML 1.1 has removed the name attribute from the a and map elements.

However, all of this is moot as the W3C position seems to be that the compatibility profile defined in XHTML 1.0 does not apply to 1.1. There is even a W3C Note on XHTML Media Types which you may find enlightening (as seems to often be the case, the pretty colors near the end are the important parts here).

Furthermore, I'd recommend reading Sending XHTML as text/html Considered Harmful by Ian Hickson.

I'll grant that XHTML 1.0 doesn't make clear either way whether its text/html compatibility profile extends to future versions, but will assume it does for a moment. So if you wish to use text/html, you must follow the guidelines of Appendix C of the XHTML 1.0 specification.

Another big one is use of the name attribute as a fragment identifier (C.8 in XHTML 1.0 spec). These are used for such things as anchors within a document. Again, 1.0 Appendix C has a suggestion that one set the id and name attributes together to the same value. And XHTML 1.1 has removed the name attribute from the a and map elements.

However, all of this is moot as the W3C position seems to be that the compatibility profile defined in XHTML 1.0 does not apply to 1.1. There is even a W3C Note on XHTML Media Types which you may find enlightening (as seems to often be the case, the pretty colors near the end are the important parts here).

Furthermore, I'd recommend reading Sending XHTML as text/html Considered Harmful by Ian Hickson.

I'll grant that XHTML 1.0 doesn't make clear either way whether its text/html compatibility profile extends to future versions, but will assume it does for a moment. So if you wish to use text/html, you must follow the guidelines of Appendix C of the XHTML 1.0 specification.

Another big one is use of the name attribute as a fragment identifier (C.8 in XHTML 1.0 spec). These are used for such things as anchors within a document. Again, 1.0 Appendix C has a suggestion that one set the id and name attributes together to the same value. And XHTML 1.1 has removed the name attribute from the a and map elements.

However, all of this is moot as the W3C position seems to be that the compatibility profile defined in XHTML 1.0 does not apply to 1.1. There is even a W3C Note on XHTML Media Types which you may find enlightening (as seems to often be the case, the pretty colors near the end are the important parts here).

Furthermore, I'd recommend reading Sending XHTML as text/html Considered Harmful by Ian Hickson.

- it breaks in Internet Explorer 5.x without MSXML 3.0 installed in replace mode

- it breaks in Internet Explorer 6.x with reasonable security settings that would prohibe the cross site access required to fetch the document type definition

- it is generally a bad idea to deliver XHTML documents using the application/xml MIME type as explained in RFC 3236 section 2

- it breaks progressive rendering

- it wastes tremendous amounts of system resources as the browser would first have to fetch the document type definition and then transform every document instead of just rendering it as the resource is retrieved; even if the document type definition is cached at some point, the browser would still emit four GET requests for every document to get 304 status

- it encourages the use of unregistered MIME types

- it does not prevent clients that actually support XHTML as application/xml and XSLT to transform the document too, which again wastes resources

- it breaks scripts that use CDATA sections to escape content as the CDATA section would be lost during the transformation

- it encourages use of illegal XHTML documents as the result of the transformation would not have a document type declaration

- it breaks content that relies on the encoding of the referring document to determine the encoding (such as HTML documents...) as the transformation result would be UTF-16 encoded and thus such content would be assumed to be UTF-16 encoded which it most likely ain't

- it breaks content that relies on one-pass white-space processing in attribute values

- it encourages the use of a .xml file name extension for XHTML documents which yields in more text/xml content on the web, which is a bad thing as everyone else is trying to wipe that type out

• TR
• TD

• TR
• TD

"XHTML 1.1 is only valid when served with the application/xhtml+xml mimetype"

Where did you get that? XHTML 1.0 specification (XHTML 1.1 doesn't say anything about mimetypes) says: "XHTML Documents which follow the guidelines set forth in Appendix C, "HTML Compatibility Guidelines" may be labeled with the Internet Media Type "text/html" [RFC2854], as they are compatible with most HTML browsers. Those documents, and any other document conforming to this specification, may also be labeled with the Internet Media Type "application/xhtml+xml" as defined in [RFC3236]. For further information on using media types with XHTML, see the informative note [XHTMLMIME]."

MSIE can't handle all valid XHTML 1.1 documents as it's buggy XML parser can't handle XHTML 1.1 DTD, but true is not that XHTML document must be served with "application/xhtml+xml" mimetype. So we can say: MSIE6 has partial XHTML support.

Writing XHTML is nothing compared to writing a semantic web annotated page. Not only do you have to worry about how the content will look, but you have to worry about how other sorts of agents will interpret it. Everything is done in an extended form of RDF (which itself is pretty much an extension of XML). The proposed languages have changed over time, from the (rather easy) SHOE meta-tag language, to the (more difficult) DAML, and finally to the current language, OWL, which is an absolute nightmare to write, especially in the full version, where there is nothing that says a page can be reasoned in finite time.

The W3C is pretty dead set on transitioning to the Semantic Web over the next few decades. XHTML is just one step on that path.

<rant> Amaya v 8.5.0.0 (apparently, the current stable version) takes an HTML 4.01 transitional page, using CSS1 and that small subset of CSS2 that happens to work across-the-board with Moz, IE and Konqueror, and trashes the layout, even tho the html and css have blessed by the w3c html [http://validator.w3.org/] and css validators [http://jigsaw.w3.org/css-validator/] -- as they were also by CSE's html validator and by Top Style's css tool).

Recognize the above is tantamount to a sideways plug (but note: no links as there would be if this were a disguised promotion) but given the stats I get off my servers, I'm going to keep on worrying about the vast preponderance of visitors who use IE, NS and Moz and who -- just BTW -- are predominantly using dialup, where compactness really counts!
</rant>

And -- re some other comments on this story -- I find XHTML to require a significant size increase to achieve the same effect as can be done compactly with 4.01 + CSS... and without, as another poster noted, spending nearly as many hours debugging as I (for one) need to clean up XHTML. Feel free to argue that that's an experience/knowledge issue, but what are we gonna' do for those whose real contribution to the net is content -- ideas, pictures, arguments -- rather than scrupulous code.

<rant> Amaya v 8.5.0.0 (apparently, the current stable version) takes an HTML 4.01 transitional page, using CSS1 and that small subset of CSS2 that happens to work across-the-board with Moz, IE and Konqueror, and trashes the layout, even tho the html and css have blessed by the w3c html [http://validator.w3.org/] and css validators [http://jigsaw.w3.org/css-validator/] -- as they were also by CSE's html validator and by Top Style's css tool).

Recognize the above is tantamount to a sideways plug (but note: no links as there would be if this were a disguised promotion) but given the stats I get off my servers, I'm going to keep on worrying about the vast preponderance of visitors who use IE, NS and Moz and who -- just BTW -- are predominantly using dialup, where compactness really counts!
</rant>

And -- re some other comments on this story -- I find XHTML to require a significant size increase to achieve the same effect as can be done compactly with 4.01 + CSS... and without, as another poster noted, spending nearly as many hours debugging as I (for one) need to clean up XHTML. Feel free to argue that that's an experience/knowledge issue, but what are we gonna' do for those whose real contribution to the net is content -- ideas, pictures, arguments -- rather than scrupulous code.

<rant> Amaya v 8.5.0.0 (apparently, the current stable version) takes an HTML 4.01 transitional page, using CSS1 and that small subset of CSS2 that happens to work across-the-board with Moz, IE and Konqueror, and trashes the layout, even tho the html and css have blessed by the w3c html [http://validator.w3.org/] and css validators [http://jigsaw.w3.org/css-validator/] -- as they were also by CSE's html validator and by Top Style's css tool).

Recognize the above is tantamount to a sideways plug (but note: no links as there would be if this were a disguised promotion) but given the stats I get off my servers, I'm going to keep on worrying about the vast preponderance of visitors who use IE, NS and Moz and who -- just BTW -- are predominantly using dialup, where compactness really counts!
</rant>

And -- re some other comments on this story -- I find XHTML to require a significant size increase to achieve the same effect as can be done compactly with 4.01 + CSS... and without, as another poster noted, spending nearly as many hours debugging as I (for one) need to clean up XHTML. Feel free to argue that that's an experience/knowledge issue, but what are we gonna' do for those whose real contribution to the net is content -- ideas, pictures, arguments -- rather than scrupulous code.

If Google said that "You must tag all "buyable things" in this format, or you don't get into our index", we'd see it happen.

Putting your documents into well marked-up documents like XML and XHTML actually makes it easier for search engines (and other user agents as it says in the FAQ linked on in the /. article.) to get to your content.

Man, do you remember when writing a webpage by hand was easy? Back in 1996 or so when just about anybody with a text editor and a link to that excellent Netscape HTML manual could write a decent page without spending hours poring over obtuse documentation?

Now you have to figure out what Doctype to set, learn CSS, enter some sort of weird workaround for IE, etc... Worse, HTML used to be fairly forgiving for the author so Newbies could get a decent page without spending hours and hours trying to figure out why their page is coming up blank or trying to figure out why the validator is complaining at them. (I really hate when it says stuff like: Illegal use of <B>. And I'm left scratching my head as to why it is illegal.). It's no wonder newbies choose instead to write their webpage in Word and use the horrible "export to HTML" feature.

Enough to do what? Build a website that will be usable by most people? It certainly isn't. Are you saying that you think that, as long as a document is valid, a surfer will have little difficulty in reading it?

Enough to have a web site that works. If it "certianly isn't", then why does my HTML seem to work just fine between IE and Mozilla?

Because you happen to use the subset of HTML that works in those browsers and don't trigger any of their bugs. Since you aren't a fan of giving buggy browsers special consideration, I can only assume that this is simply a happy accident.

Because coding to spec instantly makes that site completely unuseable?

I never said that either.

You didn't explicity say that, sure, but that's what you're implying, because everything I've said so far is in defense of using the spec and not putting in "fixes", and we're disagreeing somewhere.

I am not saying that valid code instantly makes something unusable. I am saying that, given that no browser has flawless support for the specifications, you have no reasonable basis for believing that valid (or invalid, for that matter) code will work in any given browser unless you test in it. Like I keep saying, validation isn't enough to ensure things work.

Are you saying that there is an HTML document type out there that mainstream browsers can handle without fault? Please provide exact names and versions of both the document type and the browsers that can supposedly handle it.

Sure. HTML 4.0 Strict. Everything I've written that complied with that standard seems to work just fine and dandy under IE 5/6, and versions of Mozilla from 1.0 on up.

Okay, then try this HTML 4.0 Strict document in those browsers. It's valid, it's perfectly sane code and it doesn't use any special tricks.

In Safari 1.0.2, Mozilla 1.4, Mozilla 1.6, OmniWeb 4.5, Firefox 0.8, Konqueror 3.2.3, Dillo 0.8.0, w3m 0.5.1 and Links 2.1pre11, it displays a blank page.

In Opera 6.03, Opera 7.52, Netscape 4.79 and Windows Internet Explorer 5.0, 5.5 & 6.0, it displays the source code.

In Mac Internet Explorer 5.2.3, it displays the source code in the title bar.

Lynx 2.8.5rel.1 gets closest, actually displaying the content, but with slashes all over the place.

Now that's about as simple an HTML 4.0 document as you can get, containing nothing but a paragraph saying "This is a test.". According to you, as long as it's valid (and it is), I don't have a problem, right? After all, it's not my fault, it's the fault of browser creators. Suppose I triggered these browser bugs on a production website. Which browser would you suggest I tell people to switch to?

No, it's not complicated stuff, but it does render properly, and does adhere to HTML 4.0 Strict.

Well that's great, but deliberately or not, you are only using the bits of HTML that work in common browsers and are avoiding the bits that don't work in common browsers. Valid HTML isn't enough to make a website that works; you need to give special consideration to browsers with bugs. In your case, you do so by avoiding code that is valid but that browsers have difficulty with.

So your initial point that you can display a warning to incompatible browsers wasn't wholly true then, was it? Modification of the browser is not necessary either.

It's entirely true, it just may be ineffective with a small group of people

So it's "entirely" true, except when it isn't? ;)

Gecko based browser don't seem to render span width or span height tags where IE does.

Do you mean "Gecko-based browsers ignore the width property of inline elements but Internet Explorer doesn't?" It's hard to understand what you mean when you mix up your terminology like that. Gecko is following the specification, Internet Explorer is not:

This property does not apply to non-replaced inline-level elements. The width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children).

Also think about using or creating a client side OR server side browser sniffer to get the useragent string and do some mojo based on that.

There's no way of getting reliable results from that, as User-Agent headers are routinely spoofed or missing, and Javascript is often switched off by many people.

see it here

We test using the following on web apps:

• Target browsers for intranet apps (even though we use standards as much as practically possible)
• W3C validators for HTML, CSS, and Links
• Validators within WebSphere Studio (Java, JSP, HTML), HomeSite (HTML) and TopStyle (CSS)
• JavaScript Console and Debugger in Mozilla/Firefox
• JUnit
• Cactus
• People. The users. The project owners. Us. Other web developers on e-mail lists.

• We aren't currently using an automated tool to test the front-end flow, because we haven't found any good, easy-to-use, and cheap tools that support a modern version of DOM/JavaScript usage. If you know of something that you like and works, I'd love to know about it. I've tried httpUnit, but had trouble setting it up and it didn't support all the DOM methods we were using at the time.

We test using the following on web apps:

• Target browsers for intranet apps (even though we use standards as much as practically possible)
• W3C validators for HTML, CSS, and Links
• Validators within WebSphere Studio (Java, JSP, HTML), HomeSite (HTML) and TopStyle (CSS)
• JavaScript Console and Debugger in Mozilla/Firefox
• JUnit
• Cactus
• People. The users. The project owners. Us. Other web developers on e-mail lists.

• We aren't currently using an automated tool to test the front-end flow, because we haven't found any good, easy-to-use, and cheap tools that support a modern version of DOM/JavaScript usage. If you know of something that you like and works, I'd love to know about it. I've tried httpUnit, but had trouble setting it up and it didn't support all the DOM methods we were using at the time.

We test using the following on web apps:

• Target browsers for intranet apps (even though we use standards as much as practically possible)
• W3C validators for HTML, CSS, and Links
• Validators within WebSphere Studio (Java, JSP, HTML), HomeSite (HTML) and TopStyle (CSS)
• JavaScript Console and Debugger in Mozilla/Firefox
• JUnit
• Cactus
• People. The users. The project owners. Us. Other web developers on e-mail lists.

• We aren't currently using an automated tool to test the front-end flow, because we haven't found any good, easy-to-use, and cheap tools that support a modern version of DOM/JavaScript usage. If you know of something that you like and works, I'd love to know about it. I've tried httpUnit, but had trouble setting it up and it didn't support all the DOM methods we were using at the time.

Still sticking with just HTTP and RSS as it is now, some kind of if-modified-since HTTP request would greatly reduce the load. That or a checksum. Or a date-time stamp.

It would also be possible and more complex to make a TCP or UDP based RSS designed to be robust and minimize effects of heavy use. A lot of information can be crammed into a single UDP packet, or it could just be a checksum or even just a date-time stamp.

The fault lies squarely with people still using MSIE and with OEMs for not bundling a proper web browser.

However, in a different context, Ed Foster does have a good point ... as he often does. In the case were sites have been compromised or used to spread malware, it is essential that the public be informed.

Or, people could just use a standard format for their forms which can not only be processed by native clients with as much eye candy as the developer wants, but can also be embedded in SVG and XHTML.

perhaps because that supposed html 3.2 is a horrible unsemantic mess of table tags, and invalid markup

I'm not sure what you mean by "XML parsing (last time I checked SVG couldn't do that in its authoring tool)"--what is the SVG authoring tool? Sodipodi or such?

The authoring tool--if that means editor--what I use is a text editor--in jEdit, for example, with the dandy XML plug-ins installed (thank y'all who work on all that), the SVG gets parsed & validated against the DTD, keeps things clean--did you mean something else by "XML parsing"?

Your other two points are clear, & largely accurate.

For video--& if you're using Flash as the comparison, I guess you mean synchronized sound and animation--that isn't really part of the intention of SVG's design. For that, look critically to SMIL.

Browser support on the web--aiiee--you got that right, apart from Amaya. Surprised me, how excited I got when Brendan Eich declared native SVG support a priority. Come on, Cairo, come on, come on.

I'm not sure what you mean by "XML parsing (last time I checked SVG couldn't do that in its authoring tool)"--what is the SVG authoring tool? Sodipodi or such?

The authoring tool--if that means editor--what I use is a text editor--in jEdit, for example, with the dandy XML plug-ins installed (thank y'all who work on all that), the SVG gets parsed & validated against the DTD, keeps things clean--did you mean something else by "XML parsing"?

Your other two points are clear, & largely accurate.

For video--& if you're using Flash as the comparison, I guess you mean synchronized sound and animation--that isn't really part of the intention of SVG's design. For that, look critically to SMIL.

Browser support on the web--aiiee--you got that right, apart from Amaya. Surprised me, how excited I got when Brendan Eich declared native SVG support a priority. Come on, Cairo, come on, come on.

I'm not sure what you mean by "XML parsing (last time I checked SVG couldn't do that in its authoring tool)"--what is the SVG authoring tool? Sodipodi or such?

The authoring tool--if that means editor--what I use is a text editor--in jEdit, for example, with the dandy XML plug-ins installed (thank y'all who work on all that), the SVG gets parsed & validated against the DTD, keeps things clean--did you mean something else by "XML parsing"?

Your other two points are clear, & largely accurate.

For video--& if you're using Flash as the comparison, I guess you mean synchronized sound and animation--that isn't really part of the intention of SVG's design. For that, look critically to SMIL.

Browser support on the web--aiiee--you got that right, apart from Amaya. Surprised me, how excited I got when Brendan Eich declared native SVG support a priority. Come on, Cairo, come on, come on.

Bzzt, you've just sounded my "utterly clueless" alarm.

Firstly, nobody is talking about prohibiting Javascript. The person I was responding to was talking about requiring Javascript support. It's perfectly possibly to use Javascript without requiring it.

Not just that, but the first and foremost accessibility requirements are the ones laid out by the W3C. What do they say?

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

So it's clear that when you are talking about what accessibility requirements are in place, you are talking directly out of your arsehole.

"A screenreader that supports modern HTML" isn't the problem. Perhaps you are unaware of what HTML and Javascript are? Javascript is not part of HTML, modern or otherwise. It's certainly not a required part of it.

Anyway, the trouble is pretty obvious: RSS is just a polling mechanism to do fakey Push. (Wired had an interesting retrospective on their infamous "PUSH IS THE FUTURE" hand cover about PointCast.) And that's expensive, the cyber equivalent of a hoarde of screaming children asking "Are we there yet? Are we there yet? How about now? Are we there yet now? Are we there yet?" It would be good if we had an equally widely used "true Push" standard, where remote clients would register as listeners, and then the server can actually publish new content to the remote sites. However, in today's heavily firewall'd internet, I dunno if that would work so well, especially for home users.

Actually, it's more like someone saying over and over: "What's New?"

How to make this work well, without overloading anything is the trick. I figgure there are two things to do.

1. On the Server Side make the RSS feed a static file, updated automatically only when there are changes. Then serve it with a standard cache/webserver setup.
2. On the client side make RSS readers properly use the If-Modified-Since header. It's important that this be a request for a static file because most webservers will always run the script if the URL refers to one.

This changes the conversation in most cases from "What's New?"-"(thinking...thinking...)These Things are relatively new." to "What's New?"-"Nothing." most of the time.

413 Request Entity Too Large

The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.

This suggests to me an overwhelmed RSS server could return a 413 error code with a randomized Retry-After header on the order of a couple of minutes. It seems to me that such a reply would help lessen the load on the server, as it wouldn't have to deal with content, even if said content was already cached.

If the problem is simply that of having too many open connections, then yeah, I guess you're hosed.

The folks over at Netscape and/or UserLand should have studied the CDF standard first. Then they would have realized the value of specifying schedule information.

Other useful validators:

W3C CSS Validator
XHTML Validator

And.. HTML Tidy to clean up code.

Other useful validators:

W3C CSS Validator
XHTML Validator

And.. HTML Tidy to clean up code.

Other useful validators:

W3C CSS Validator
XHTML Validator

And.. HTML Tidy to clean up code.

The W3C Validator is your friend. There's also one for validating CSS.

It's not perfect, however, so take it with a (small) pinch of salt.

The W3C Validator is your friend. There's also one for validating CSS.

It's not perfect, however, so take it with a (small) pinch of salt.

Generally I'll do the dev work in $Mozilla-variant-of-the-week, but trying to keep with W3C standards and checking heavily against the validator. Provided the page is valid against various standards (HTML 4.01 Transitional as a minimum), and it renders ok in both Moz and IE, I'm happy. OTOH, I'm no longer a professional web developer (I have better things to do these days), and for a big client I'd want to check against various other platforms.

http://validator.w3.org/

Uh, which W3C standard(s) should I follow?

Sometimes I'm just baffled at what they want me to do.

They may be a bunch of meeting-bound administrators, but W3C do produce working code to their own specifications.

Interesting URL (I spent about fifteen minutes reading about lojban, but next time please make a link.

When I tell people I work for the inventor of the Web, their first response is always,

``Didn't Al Gore invent that?''

Then I have to go into a long tedious explanation about how Al Gore invented the Intenet, and the Web is only one application of it.

I personally would prefer that Tim would keep on going on these long trips to get awards. Getting things done on Cwm without direction from Tim on what Cwm should actually do is getting hard. I've been spending more time at work on slashdot as result.

In this day and age of superfluous patents and frivolous lawsuits, Sir Tim Berners-Lee gently reminds us of the importance of free and selfless contribution for the betterment of humanity. Speaking at the ceremony for winning the Millennium Technology Prize (as reported earlier on Slashdot), he said that he would never have succeeded if he'd tried to charge money for his inventions. The prize committee agreed, citing the importance of Berners-Lee's decision never to commercialize or patent his contributions to the Internet technologies he had developed, and recognizing his revolutionary contribution to humanity's ability to communicate.

From the article: ""Different people and different organizations have divergent views on what constitutes the common good, on what constitutes acceptable and desirable goals, and what are legitimate and ethical constraints," Auerbach wrote..."

It's interesting to watch the dynamic that is the evolution of the administration of the net. ICANN is seen by much of the world as to American centric and requiring, possibly a UN governing body to replace it or some other world centric governing body. Perhaps the growing pains of the European Union could offer some lessons as to how to best govern the net. It must irk many nations and organizations to see the administration and future plans for the net played out in American courts.

Tim Berners-Lee saw the founding of the web as a world wide endeavour surely a body as important as ICANN should be under the ageis of the UN?

If he is worried about this that much, he should find a legitimite solution to the problem.