Slashdot Mirror

This article explores the ins and outs of XML namespaces and their ramifications on a number of XML technologies that support namespaces. What follows is a shortened version of my first Extreme XML column.

As XML usage on the Internet became more widespread, the benefits of being able to create markup vocabularies that could be combined and reused similarly to how software modules are combined and reused became increasingly important. If a well defined markup vocabulary for describing coin collections, program configuration files, or fast food restaurant menus already existed, then reusing it made more sense than designing one from scratch. Combining multiple existing vocabularies to create new vocabularies whose whole was greater than the sum of its parts also became a feature that users of XML began to require.

However, the likelihood of identical markup, specifically XML elements and attributes, from different vocabularies with different semantics ending up in the same document became a problem. The very extensibility of XML and the fact that its usage had already become widespread across the Internet precluded simply specifying reserved elements or attribute names as the solution to this problem.

The goal of the W3C XML namespaces recommendation was to create a mechanism in which elements and attributes within an XML document that were from different markup vocabularies could be unambiguously identified and combined without processing problems ensuing. The XML namespaces recommendation provided a method for partitioning various items within an XML document based on processing requirements without placing undue restrictions on how these items should be named. For instance, elements named <template>, <output>, and <stylesheet> can occur in an XSLT stylesheet without there being ambiguity as to whether they are transformation directives or potential output of the transformation.

An XML namespace is a collection of names, identified by a Uniform Resource Identifier (URI) reference, which are used in XML documents as element and attribute names.

A namespace declaration is typically used to map a namespace URI to a specific prefix. The scope of the prefix-namespace mapping is that of the element that the namespace declaration occurs on as well as all its children. An attribute declaration that begins with the prefix xmlns: is a namespace declaration. The value of such an attribute declaration should be a namespace URI which is the namespace name.

Here is an example of an XML document where the root element contains a namespace declaration that maps the prefix bk to the namespace name urn:xmlns:25hoursaday-com:bookstore and its child element contains an inventory element that contains a namespace declaration that maps the prefix inv to the namespace name urn:xmlns:25hoursaday-com:inventory-tracking.

In the above example, the scope of the namespace declaration for the urn:xmlns:25hoursaday-com:bookstore namespace name is the entire bk:bookstore element, while that of the urn:xmlns:25hoursaday-com:inventory-tracking is the inv:inventory element. Namespace aware processors can process items from both namespaces independently of each other, which leads to the ability to do multi-layered processing of XML documents. For instance, RDDL documents are valid XHTML documents that can be rendered by a Web browser but also contain information using elements from the http://www.rddl.org namespace that can be used to locate machine readable resources about the members of an XML namespace.

It should be noted that by definition the prefix xml is bound to the XML namespace name and this special namespace is automatically predeclared with document scope in every well-formed XML document.

The previous section on namespace declarations is not entirely complete because it leaves out default namespaces. A default namespace declaration is an attribute declaration that has the name xmlns and its value is the namespace URI that is the namespace name.

A default namespace declaration specifies that every unprefixed element name in its scope be from the declaring namespace. Below is the bookstore example utilizing a default namespace instead of a prefix-namespace mapping.

All the elements in the above example except for the inv:inventory element belong to the urn:xmlns:25hoursaday-com:bookstore namespace. The primary purpose of default namespaces is to reduce the verbosity of XML documents that utilize namespaces. However, using default namespaces instead of utilizing explicitly mapped prefixes for element names can be confusing because it is not obvious that the elements in the document are namespace scoped.

Also, unlike regular namespace declarations, default namespace declarations can be undeclared by setting the value of the xmlns attribute to the empty string. Undeclaring default namespace declarations is a practice that should be avoided because it may lead to a document that has unprefixed names that belong to a namespace in one part of the document, but don't in another. For example, in the document below only the bookstore element is from the urn:xmlns:25hoursaday-com:bookstore while the other unprefixed elements have no namespace name.

This practice should be avoided because it leads to extremely confusing situations for readers of the XML document. For more information on undeclaring namespace declarations, see the section on Namespaces Future.

A qualified name, also known as a QName, is an XML name called the local name optionally preceded by another XML name called the prefix and a colon (':') character. The XML names used as the prefix and the local name must match the NCName production, which means that they must not contain a colon character. The prefix of a qualified name must have been mapped to a namespace URI through an in-scope namespace declaration mapping the prefix to the namespace URI. A qualified name can be used as either an attribute or element name.

Although QNames are important mnemonic guides to determining what namespace the elements and attributes within a document are derived from, they are rarely important to XML aware processors. For example, the following three XML documents would be treated identically by a range of XML technologies including, of course, XML schema validators.

The W3C XML Path Language recommendation describes an expanded name as a pair consisting of a namespace name and a local name. A universal name is an alternate term coined by James Clark to describe the same concept. A universal name consists of a namespace name in curly braces and a local name. Namespaces tend to make more sense to people when viewed through the lens of universal names. Here are the three XML documents from the previous example with the QNames replaced by universal names. Note that the syntax below is not valid XML syntax.

To many XML applications, the universal name of the elements and attributes in an XML document are what is important, and not the values of the prefixes used in specific QNames. The primary reason the Namespaces in XML recommendation does not take the expanded name approach to specifying namespaces is due to its verbosity. Instead, prefix mappings and default namespaces are provided to save us all from developing carpal tunnel syndrome from typing namespace URIs endlessly.

Namespace declarations do not apply to attributes unless the attribute's name is prefixed. In the XML document shown below the title attribute belongs to the bk:book element and has no namespace while the bk:title attribute has urn:xmlns:25hoursaday-com:bookstore as its namespace name. Note that even though both attributes have the same local name the document is well formed.

In the following example, the title attribute still has no namespace and belongs the book element even though there is a default namespace specified. In other words, attributes cannot inherit the default namespace.

A namespace name is a Uniform Resource Identifier (URI) as specified in RFC 2396. A URI is either a Uniform Resource Locators (URLs) or a Uniform Resource Names (URNs). URLs are used to specify the location of resources on the Internet, while URNs are supposed to be persistent, location-independent identifiers for information resources. Namespace names are considered to be identical only if they are the same character for character (case-sensitive). The primary justification for using URIs as namespace names is that they already provide a mechanism for specifying globally unique identities.

The XML namespaces recommendation states that namespace names are only to act as unique identifiers and do not have to actually identify network retrievable resources. This has led to much confusion amongst authors and users of XML documents, especially since the usage of HTTP based URLs as namespace names has grown in popularity. Because many applications convert such URIs to hyperlinks, it is irritating to many users that these "links" do not lead to Web pages or other network retrievable resource. I remember one user who likened it to being given a fake phone number in a social situation.

One solution to avoid confusing users is to use a namespace-naming schema that does not imply network retrievability of the resource. I personally use the urn:xmlns: scheme for this purpose and create namespace names similar to urn:xmlns:25hoursaday-com when authoring XML documents for personal use. The problem with homegrown namespace URIs is that they may run counter to the intent of the Names in XML recommendation by not being globally unique. I get around the globally unique requirement by using my personal domain name http://www.25hoursaday.com as part of the namespace URI.

Another solution is to leave a network retrievable resource at the URI that is the namespace name, such as is done with the XSLT and RDDL namespaces. Typically, such URIs are actually HTTP URLs. A good way to name such URLs is by using the format favored by the W3C, which is as follows:

See the section on Namespaces and Versioning for more information on using similarly structured namespace names as a versioning mechanism.

The W3C has defined a number of technologies that provide a data model for XML documents. These data models are generally in agreement, but sometimes differ in how they treat various edge cases due to historic reasons. Treatment of XML namespaces and namespace declarations is an example of an edge case that is treated differently in the three primary data models that exist as W3C recommendations. The three data models are the XPath data model, the Document Object Model (DOM), and the XML information set.

The XML information set (XML infoset) is an abstract description of the data in an XML document and can be considered to be the primary data model for an XML document. The XPath data model is a tree-based model that is traversed when querying an XML document and is similar to the XML information set. The DOM precedes both data models but is also similar to both data models in a number of ways. Both the DOM and the XPath data model can be considered to be interpretations of the XML infoset.

The XML namespace section of the DOM Level 3 specification considers namespace declarations to be regular attribute nodes that have http://www.w3.org/2000/xmlns/ as their namespace name and xmlns as their prefix or qualified name.

Elements and attributes in the DOM have a namespace name that cannot be altered after they have been created regardless of whether their location within the document changes or not.

The W3C XPath recommendation does not consider namespace declarations to be attribute nodes and does not provide access to them in that capacity. Instead, in XPath every element in an XML document has a number of namespace nodes that can be retrieved using the XPath namespace navigation axis.

Each element in the document has a unique set of namespace nodes for each namespace declaration in scope for that particular element. Namespace nodes are unique to each element in that namespace. Thus namespace nodes for two different elements that represent the same namespace declaration are not identical.

The XML infoset recommendation considers namespace declarations to be attribute information items.

In addition, similar to the XPath data model, each element information item in an XML document's information set has a namespace information item for each namespace that is in scope for the element.

The W3C XML Path Language also known as XPath is used to address parts of an XML document and is used in a number of W3C XML technologies including XSLT, XPointer, XML Schema, and DOM Level 3. XPath uses a hierarchical addressing mechanism similar to that used in file systems and URLs to retrieve pieces of an XML document. XPath supports rudimentary manipulation of strings, numbers, and Booleans.

The XPath data model treats an XML document as a tree of nodes, such as element, attribute, and text nodes, where the name of each node is a combination of its local name and its namespace name (that is, its universal or expanded name).

For element and attribute nodes without namespaces, performing XPath queries is fairly straightforward. The following program, which can be used to query XML documents using the command line, shall be used to demonstrate the impact of namespaces on XPath queries.

Given the following XML document that does not declare any namespaces, queries are fairly straightforward as seen in the examples following the code.

xpathquery.exe bookstore.xml /bookstore/book/title

Selects all the title elements that are children of the book element whose parent is the bookstore element, which returns:
<title>The Autobiography of Benjamin Franklin</title>
<title>The Confidence Man</title>

xpathquery.exe bookstore.xml //@genre

Select all the genre attributes in the document and returns:
genre="autobiography"
genre="novel"

xpathquery.exe bookstore.xml //title[(../author/first-name = 'Herman')]

Selects all the titles where the author's first name is "Herman" and returns:
<title>The Confidence Man</title>

However, once namespaces are added to the mix, things are no longer as simple. The file below is identical to the original file except for the addition of namespaces and one attribute to one of the book elements.

Note that the default namespace is in scope for the whole XML document, while the namespace declaration that maps the prefix bk to the namespace name urn:xmlns:25hoursaday-com:bookstore is in scope for the second book element only. Example 2

xpathquery.exe bookstore.xml /bookstore/book/title

Selects all the title elements that are children of the book element whose parent is the bookstore element, which returns NO RESULTS.

xpathquery.exe bookstore.xml //@genre

Selects all the genre attributes in the document and returns:
genre="autobiography"
genre="novel"

xpathquery.exe bookstore.xml //title[(../author/first-name = 'Herman')]

Selects all the titles where the author's first name is "Herman," which returns NO RESULTS.

The first query returns no results because unprefixed names in an XPath query apply to elements or attributes with no namespace. There are no bookstore, book, or title elements in the target document that have no namespace. The second query returns all attribute nodes that have no namespace. Although namespace declarations are in scope for both attribute nodes returned by the query, they have no namespace because namespace declarations do not apply to attributes with unprefixed names. The third query returns no results for the same reasons the first query returns no results.

The way to perform namespace-aware XPath queries is to provide a prefix to namespace mapping to the XPath engine, then use those prefixes in the query. The prefixes provided do not need to be the same as the namespace to prefix mappings in the target document, and they must be non-empty prefixes. Example 3

xpathquery.exe bookstore.xml /b:bookstore/b:book/b:title b urn:xmlns:25hoursaday-com:bookstore

Select all the title elements that are children of the book element whose parent is the bookstore element and returns the following:
<title xmlns="urn:xmlns:25hoursaday-com:bookstore">The Autobiography of Benjamin Franklin</title>
<bk:title xmlns:bk="urn:xmlns:25hoursaday-com:bookstore"> The Confidence Man</bk:title>

xpathquery.exe bookstore.xml //@b:genre b urn:xmlns:25hoursaday-com:bookstore

Selects all the genre attributes from the "urn:xmlns:25hoursaday-com:bookstore" namespace in the document that returns:
bk:genre="fiction"

xpathquery.exe bookstore.xml //bk:title[(../bk:author/bk:first-na me = 'Herman')] bk urn:xmlns:25hoursaday-com:bookstore

Selects all the titles where the author's first name is "Herman" and returns:
<bk:title xmlns:bk="urn:xmlns:25hoursaday-com:bookstore"> The Confidence Man</bk:title>

Note This last example is the same as the previous examples but rewritten to be namespace aware.

For more information on using XPath, read Aaron Skonnard's article Addressing Infosets with XPath and view the examples at the ZVON.org XPath tutorial.

The W3C XSL transformations (XSLT) recommendation describes an XML-based language for transforming XML documents into other XML documents. XSLT transformations, also known as XML style sheets, utilize patterns (XPath) to match aspects of the target document. Upon matching nodes in the target document, templates that specify the output of a successful match can be instantiated and used to transform the document.

Support for namespaces is tightly integrated into XSLT, especially since XPath is used for matching nodes in the source document. Using namespaces in your XPath expressions inside XSLT is much easier than using the DOM.

The example that follows contains:

A program for use in executing transforms from the command line.

An XSLT stylesheet that prints all the title elements from the urn:xmlns:25hoursaday-com:bookstore namespace in the source XML document when run against the bookstore document from the urn:xmlns:25hoursaday-com:bookstore namespace.

The resulting output. Program Imports System.Xml.Xsl

I've found the book to be extremely useful, but then I'm working on a multiplatform GUI SSH2 client myself so my opinion may be a bit skewed.

The IETF has already thought of scenarios like the one described (a router in every car). Look at the Mobile Ad-hoc NETwork working group.

The IETF also has an IDN working group

Unicode DNS exists.

Even Microsoft supports it.

Some internet draft...
another interesting one.

There was an attempt to create a standard way of talking to keyword systems. See CNRP, RFC 2972 and recent (May 3) approval of CNRP protocol as Proposed Standard. Just in time!

There was an attempt to create a standard way of talking to keyword systems. See CNRP, RFC 2972 and recent (May 3) approval of CNRP protocol as Proposed Standard. Just in time!

Not true! The DeltaV specification, "Versioning Extensions to WebDAV" was published as RFC 3253 (Standards Track), in March, 2002.

This specification provides versioning, configuration management, workspaces, and logical change tracking capabilities.

First out the door with an implementation is the Subversion project, which is developing an Open Source replacement for CVS.

While we're at it, two other WebDAV specifications nearing completion are:
WebDAV Access Control Protocol
DAV Searching and Locating Protocol

The IETF zeroconf working group, led by Apple's Stuart Cheshire, has been working on this for a while.

> You can't mod_rewrite a domain name that you have lost control over.

Nope, that's too bad. You can mod_rewrite a domain name you do have control over, though. You can also see if you can get the new owners to redirect to your new domain.

If, say, all your URI's start with a date, you ask the new owners to redirect any URI containing '/yyyy/mm/dd' less than the date you lost the domain to your new site. You may not get it all or even most of the time, but the option is still there.

Alas, this is one of those cases URN's would come in handy.

Read the RFC at the original source. The link in the article is already broken.

Enjoy:

http://www.ietf.org/rfc/rfc3271.txt?number=3271

The official RFC3271 page at the IETF is http://www.ietf.org/rfc/rfc3271.txt?number=3271.

wizzy writes "Irelands toplevel domain registry [ http://www.domainregistry.ie/] has a notice on Microsoft and Apple DHCP [http://www.isc.org/products/DHCP/] clients sending dynamic DNS updates per RFC2136 [http://www.ietf.org/rfc/rfc2136.txt]. The problem is they are not sufficiently careful about where they send it if they are in ...

wizzy writes "Irelands toplevel domain registry ( *) has a notice on Microsoft and Apple DHCP (*) clients sending dynamic DNS updates per RFC2136 (*). The problem is they are not sufficiently careful about where they send it if they are in ...

I guess we should be happy that they don't link to Apple and Microsoft as well ;-)

wizzy writes "Irelands toplevel domain registry [ http://www.domainregistry.ie/] has a notice on Microsoft and Apple DHCP [http://www.isc.org/products/DHCP/] clients sending dynamic DNS updates per RFC2136 [http://www.ietf.org/rfc/rfc2136.txt]. The problem is they are not sufficiently careful about where they send it if they are in ...

wizzy writes "Irelands toplevel domain registry ( *) has a notice on Microsoft and Apple DHCP (*) clients sending dynamic DNS updates per RFC2136 (*). The problem is they are not sufficiently careful about where they send it if they are in ...

I guess we should be happy that they don't link to Apple and Microsoft as well ;-)

Just because the US and FCC recognises it doesn't mean the world does

These de facto standards are always present in fast-moving technology areas. To be honest I'm not sure whether I should've hammered on this fact. What really does get up my pants is when these big corporations do it - like Cisco with HSRP (Hot Standby Routing Protocol). The IETF was like wtf? They didn't even give the IETF the right darn name. I just had a time-delayed need to get payback on FUD corporate-imposed standards forced on us by large corporations, but UWB is the little guy at the moment. Doh!

Instead of P2P using thier own port system, couldn't they use Port 80 tunnelling? A RFC has even been created for it (however, the RFC addresses different issues).

Then the data shouldn't be distinguishable between web-surfing and file-sharing.

The credentials used in a public key infrastructure (PKI) typically consist of a public/private key pair, a corresponding certificate or certificate chain and some trust or root certification authority information. They are usually stored on a desktop or laptop system as part of an application specific store. Currently, support for credential export/import is uneven and end users need to get too involved with the mechanics of creating and maintaining their PKI credentials.

Application specific stores also mean that users cannot easily use the same credential in multiple applications or on multiple devices. In effect, today, credentials aren't portable. PKIs that use hardware tokens (e.g., smart cards, PCMCIA cards) do allow for portability of the user's credentials, however, most systems do not use hardware tokens, but would benefit if similar portability features were available. Ideally, users would be able to use a common set of credentials with their desktop and laptop PCs, PDAs, cell phones, and other Internet-ready devices. Even where hardware tokens are used, there may also be substantial benefit derived from using credential portability protocols in support of management functions such as, for example, installation, token recovery (e.g. locked PIN), or token replacement.

SIP blends naturally into IM and Presence as seen in this draft and this one.

SIP blends naturally into IM and Presence as seen in this draft and this one.

There is no way to shut "IRC" down. IRC is not a single entity.

Anyone can download an ircd and start their own {server,network}. It's much like gnutella or other P2P variants.

RFC 1459 defines an open standard for the IRC protocol. Anyone can implement this, much like anyone can implement their own DHCP or S/KEY implementation.

There is no central IRC authority. Operators have the scope of the network on which they reside (if even that).

*sighs*

There is no way to shut "IRC" down. IRC is not a single entity.

Anyone can download an ircd and start their own {server,network}. It's much like gnutella or other P2P variants.

RFC 1459 defines an open standard for the IRC protocol. Anyone can implement this, much like anyone can implement their own DHCP or S/KEY implementation.

There is no central IRC authority. Operators have the scope of the network on which they reside (if even that).

*sighs*

It's not security avoidance, it's stupidity avoidance. RFC 3093 and (to some extent) ssh tunnelling are in the same spirit. Until now, being able to do useful Internet communications (other than http) through a firewall has been limited to those geeky enough to set up some kind of tunnel or workaround. Well done to Microsoft for opening it up to the masses.

I feel like predicting that in five years' time _all_ major services (including NFS, etc) will operate over http, that being the only way to make them accessible to most Web users. (Gloomily assuming that IPv6 doesn't take off and ISPs continue on their current path of masquerading and transparent proxying.) Then 'next generation' firewalls will appear which are able to selectively block SOAP packets and other kinds of http requests. But to bypass that, Microsoft will soon switch to https instead, and that will be the end of firewalls. Unless you give your firewall a copy of your servers' private keys so it can snoop on communications.

Also see the World's First RFC 1149 implementation

D

[Your] friendly neighborhood ISP caches the most often used DNS info, and 80% of internet traffic is resolved there...That's why, as the article said, 8 of the 13...

Actually, the reason you'd have to take out 8 of the 13 has nothing to do with caching. It's because the root DNS servers MUST be able to handle three times the peak traffic of any one server at any time; that is, normal traffic, with all servers operating, MUST never exceed 1/3 capacity of the server in question. This is part of RFC 2870, the RFC that specifies operational details for the root servers. The RFC specifies this level of capacity to provide for redundancy; that capacity means that we can lose 2/3 of the servers without overloading the remaining boxen. 8 is just a shade less than 2/3 of 13, so that's where we get the number.

(Grammar correction mine.)

You saw the word "obscurity" and a red flag went off. That's good. However, you took it out of context and hurried up to post before you really thought about what they're saying.

They're not saying, "Our building doesn't have a lock on the door, but nobody knows where it is, so we're okay."

They're saying, "Not only is our site secure, but we're also very low-key, since in our business it's not good to attract attention."

Another example: Everyone knows where the NSA building is, but they still don't exactly put a big neon sign on the roof and run ads daring people to break in.

As i said in my reply to your other post, you need to read RFC 2870 ASAP.

You need to read RFC 2870.

So this is just a very low-powered ad hoc wireless network, then. *yawn*

They're talking about creating them to power themselves from their environment, and give examples of generating power from vibrations, or from small solar cells... which makes me wonder whether it would be possible to create picoreadio devices which power themselves from the ambient radiowaves. I know some British scientist built a radio which is entirely self-powered in this way, and it seems to me to be a great way of powering things like these (if their power requirement is low enough). Anyway...

For those who don't know, an ad hoc wireless network is a wireless network like IEEE 802.11, but entirely self configurating, etc... etc... They're pretty neat things, but there aren't any real implementations outside of the US military, so these guys will really have a first if they get picoradio done soon. They're based on such great acronym^H^H^H^H^H^H^Hprotocols such as ZRP (Zone Routing Procol) or DSDV (Destination Sequenced Distance Vector) and DSR (Dynamic Source Routing).

There is currently an IETF working group (MANET) trying to develop some standards, but there's a lot of research to be done first, so it could be a while before you see anything. Once they do put something out in a few years time, it'll kick IEEE 802.11's ass. =)

If you want more info on adhoc networks, you can look at MANET's 'official' webpage here. That page is pretty useless though, so you should look at their unofficial website here. It has links to a lot of great resources.

Ad hoc wireless networks are cool.

You might want to consider whether WebDAV is a key standard for your needs.

The WebDAV extensions to HTTP 1.1 provide a way for remote authors to manipulate files and collections, and an extensible set of file properties; and addresses issues such as locking.

A related standard provides for versioning: RFC 3253

As such, WebDAV and its associated standards effectively standardise what the various CMS and DMS vendors provide proprietary interfaces for.

The standard is now widely implemented - see www.webdav.org - both in operating systems, and particular clients and servers (although not yet in most of the aforementioned CMS/DMS). For an open source Java implementation of client and server, I use Apache Jakarta-Slide.

It is and will continue to be fascinating to watch how the incumbent CMS/DMS vendors react as their market gets commoditised.

Anyways, what's this about RFC 2505 and BCP 30?

Oops, sorry. RFC is an acronym for "Request for Comments", RFCs as published by the IETF (Internet Engineering Task Force) often have those comments already incorporated. RFC 2505 is "Anti-Spam Recommendations for SMTP MTAs".

Some RFCs are merely (but often very) funny, like RFC 1149 ("A Standard for the Transmission of IP Datagrams on Avian Carriers"), other like RFC 2821 ("Simple Mail Transfer Protocol") can not easily be ignored.
BCP means "Best Current Practice", technically not required, but rude if one ignores it. An intranet is IP-based too. ;-)

Anyways, what's this about RFC 2505 and BCP 30?

Oops, sorry. RFC is an acronym for "Request for Comments", RFCs as published by the IETF (Internet Engineering Task Force) often have those comments already incorporated. RFC 2505 is "Anti-Spam Recommendations for SMTP MTAs".

Some RFCs are merely (but often very) funny, like RFC 1149 ("A Standard for the Transmission of IP Datagrams on Avian Carriers"), other like RFC 2821 ("Simple Mail Transfer Protocol") can not easily be ignored.
BCP means "Best Current Practice", technically not required, but rude if one ignores it. An intranet is IP-based too. ;-)

Anyways, what's this about RFC 2505 and BCP 30?

Oops, sorry. RFC is an acronym for "Request for Comments", RFCs as published by the IETF (Internet Engineering Task Force) often have those comments already incorporated. RFC 2505 is "Anti-Spam Recommendations for SMTP MTAs".

Some RFCs are merely (but often very) funny, like RFC 1149 ("A Standard for the Transmission of IP Datagrams on Avian Carriers"), other like RFC 2821 ("Simple Mail Transfer Protocol") can not easily be ignored.
BCP means "Best Current Practice", technically not required, but rude if one ignores it. An intranet is IP-based too. ;-)

Anyways, what's this about RFC 2505 and BCP 30?

Oops, sorry. RFC is an acronym for "Request for Comments", RFCs as published by the IETF (Internet Engineering Task Force) often have those comments already incorporated. RFC 2505 is "Anti-Spam Recommendations for SMTP MTAs".

Some RFCs are merely (but often very) funny, like RFC 1149 ("A Standard for the Transmission of IP Datagrams on Avian Carriers"), other like RFC 2821 ("Simple Mail Transfer Protocol") can not easily be ignored.
BCP means "Best Current Practice", technically not required, but rude if one ignores it. An intranet is IP-based too. ;-)

It's true that you should follow the RFC's, but a lot go unnoticed. Take RFC 3118 for example. Does your linux box follow it? Probably not. There are a ton of RFC's that people don't follow, even Cisco.

Well, a quote from the 12 networking truths (RFC 1925):

...

11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
...

Maybe because they're labeled experimental?

They have been on the standards track for two years. Check RFC 2782 which obsoletes RFC 2052.

Maybe because they're labeled experimental?

Also see RFC2100, "The Naming of Hosts"

RFC 1178, Choosing a Name for Your Computer

RFC 2142 outlines the standard mailbox names that every organization should have. (I tried to paste the list in, but the stupid lameness filter kept complaining about "junk characters".)

PGP is a good solution to email security. However, commercial software is mostly now using S/MIME, which is probably not less secure (if you use a good algorithm and reasonable-length keys). S/MIME is specified in a bunch of RFCs and is actively being extended and improved (see the IETF site for details). You can get open-source code for it (e.g. it is part of Mozilla).

The DNS protocol itself is 8-bit clean, so even BIND can handle UTF-8 characters. That isn't the problem. Go read some of the drafts for a much better treatment than I could give.

But let's not start doling out domains before the solution is complete. And it's not.

This exists. It's called IPSec and there is no reason that it should not be running on all your wireless links. For pete's sake, there's even IPSec implementations for Palm OS and WinCE.

We don't need a new security protocol, we just need to implement and use the ones we have (IPSec, ssh, ssl) properly. I'd rather see wireless lan cards come out with 3DES, AES, RSA, SHA-1 etc. hardware acceleration (and open documentation) than yet an other wireless "security" protocol that hasn't been peer reviewed properly.

... which is in direct violation of SMTP:

As discussed in section 2.4.1, a relay SMTP has no need to inspect or act upon the headers or body of the message data and MUST NOT do so except to add its own "Received:" header (section 4.4) and, optionally, to attempt to detect looping in the mail system (see section 6.2).

Actually, there are many, many, many Whois databases. Check out section 2.1 of this Internet draft for an overview of them. (I'm listed as co-author, but Andrew Newton did 95% of the work.)

I work in the database group at the RIPE NCC, and there are actually more privacy problems with the IP database than I'm comfortable with. We do our best to protect user information, but of course we also have an obligation to make the information available to those who genuinely need it. It's a tough balance to maintain, since we are a public resource, and do not require registration of any kind to access the database.

The Regional Internet Registry (RIR) community has guidelines defining the largest network that can be listed without providing end-user contact information. Currently, any network bigger than a /29 (more than 8 IP addresses) needs to have contact information of a person on-site.

One of the great things about the RIPE NCC and the other RIR's is that if you don't like the policy, you can change it. :)

However, I wouldn't mark this particular moderator down. Your post was a list of complaints about what other people are doing to solve a real problem with no solution of your own to offer or any reason why its not a problem. Personally I wouldn't mark it as a troll but I think it's borderline.

See, this is what you should have put in the original post.

Most of the people I know haven't even upgraded to IPv5 yet!

With IPv6, address space assigned to large ISPs will be a lot better aggregated. Of course that won't stop them from breaking it up into a lot of prefixes, but hopefully that will only be for their really sub-autonomous networks. Lots of big ISPs were given some big chunks like /16, but they got those many times. So that means many prefixes announced even if they could aggregate them if adjacent. At least with IPv6 they can be given all the space they will need for 100+ years right now.

Routing in IPv6 is also different. The low 64 bits as I understand it won't play any part as that is pretty much going to a single LAN, so the routing announcements shouldn't need any more than the high 64 bits, and maybe even just the high 32 bits. Here's the list of RFCs that match string search for "ipv6" and "route". I haven't actually read them, so maybe you can easily find where I'm all wrong.

rfc1752|rfc1809|rfc1825|rfc1883|rfc1884|rfc1887|rf c1888|rfc1933|rfc1970|rfc1981|rfc1999|rfc2000|rfc2 019|rfc2080|rfc2101|rfc2185|rfc2199|rfc2200|rfc229 2|rfc2300|rfc2353|rfc2373|rfc2400|rfc2401|rfc2460| rfc2461|rfc2465|rfc2466|rfc2473|rfc2491|rfc2492|rf c2500|rfc2526|rfc2529|rfc2545|rfc2546|rfc2590|rfc2 600|rfc2626|rfc2700|rfc2710|rfc2711|rfc2740|rfc274 5|rfc2746|rfc2765|rfc2766|rfc2767|rfc2772|rfc2799| rfc2800|rfc2874|rfc2884|rfc2893|rfc2894|rfc2899|rf c2900|rfc2956|rfc2983|rfc3000|rfc3002|rfc3053|rfc3 056|rfc3068|rfc3089|rfc3111|rfc3132|rfc3162|rfc317 5|rfc3178|rfc3234

With IPv6, address space assigned to large ISPs will be a lot better aggregated. Of course that won't stop them from breaking it up into a lot of prefixes, but hopefully that will only be for their really sub-autonomous networks. Lots of big ISPs were given some big chunks like /16, but they got those many times. So that means many prefixes announced even if they could aggregate them if adjacent. At least with IPv6 they can be given all the space they will need for 100+ years right now.

Routing in IPv6 is also different. The low 64 bits as I understand it won't play any part as that is pretty much going to a single LAN, so the routing announcements shouldn't need any more than the high 64 bits, and maybe even just the high 32 bits. Here's the list of RFCs that match string search for "ipv6" and "route". I haven't actually read them, so maybe you can easily find where I'm all wrong.

rfc1752|rfc1809|rfc1825|rfc1883|rfc1884|rfc1887|rf c1888|rfc1933|rfc1970|rfc1981|rfc1999|rfc2000|rfc2 019|rfc2080|rfc2101|rfc2185|rfc2199|rfc2200|rfc229 2|rfc2300|rfc2353|rfc2373|rfc2400|rfc2401|rfc2460| rfc2461|rfc2465|rfc2466|rfc2473|rfc2491|rfc2492|rf c2500|rfc2526|rfc2529|rfc2545|rfc2546|rfc2590|rfc2 600|rfc2626|rfc2700|rfc2710|rfc2711|rfc2740|rfc274 5|rfc2746|rfc2765|rfc2766|rfc2767|rfc2772|rfc2799| rfc2800|rfc2874|rfc2884|rfc2893|rfc2894|rfc2899|rf c2900|rfc2956|rfc2983|rfc3000|rfc3002|rfc3053|rfc3 056|rfc3068|rfc3089|rfc3111|rfc3132|rfc3162|rfc317 5|rfc3178|rfc3234

With IPv6, address space assigned to large ISPs will be a lot better aggregated. Of course that won't stop them from breaking it up into a lot of prefixes, but hopefully that will only be for their really sub-autonomous networks. Lots of big ISPs were given some big chunks like /16, but they got those many times. So that means many prefixes announced even if they could aggregate them if adjacent. At least with IPv6 they can be given all the space they will need for 100+ years right now.

Routing in IPv6 is also different. The low 64 bits as I understand it won't play any part as that is pretty much going to a single LAN, so the routing announcements shouldn't need any more than the high 64 bits, and maybe even just the high 32 bits. Here's the list of RFCs that match string search for "ipv6" and "route". I haven't actually read them, so maybe you can easily find where I'm all wrong.

rfc1752|rfc1809|rfc1825|rfc1883|rfc1884|rfc1887|rf c1888|rfc1933|rfc1970|rfc1981|rfc1999|rfc2000|rfc2 019|rfc2080|rfc2101|rfc2185|rfc2199|rfc2200|rfc229 2|rfc2300|rfc2353|rfc2373|rfc2400|rfc2401|rfc2460| rfc2461|rfc2465|rfc2466|rfc2473|rfc2491|rfc2492|rf c2500|rfc2526|rfc2529|rfc2545|rfc2546|rfc2590|rfc2 600|rfc2626|rfc2700|rfc2710|rfc2711|rfc2740|rfc274 5|rfc2746|rfc2765|rfc2766|rfc2767|rfc2772|rfc2799| rfc2800|rfc2874|rfc2884|rfc2893|rfc2894|rfc2899|rf c2900|rfc2956|rfc2983|rfc3000|rfc3002|rfc3053|rfc3 056|rfc3068|rfc3089|rfc3111|rfc3132|rfc3162|rfc317 5|rfc3178|rfc3234