Slashdot Mirror

The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.

Let's do exactly what you suggest, and "RTFM". From the Acid3 page at webstandards.org, with links to the specifications and dates added by me:

Here is the list of specifications tested:

• DOM2 Core [specification published in 2000.]
• DOM2 Events [specification published in 2000.]
• DOM2 HTML [specification published in 2003.]
• DOM2 Range [specification published in 2000.]
• DOM2 Style (getComputedStyle, ...) [specification published in 2000.]
• DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
• DOM2 Views (defaultView) [specification published in 2000.]
• ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
• HTML4 (<object>, <iframe>, ...) [specification published in 1997.]
• HTTP (Content-Type, 404, ...) [specification published in 1999.]
• Media Queries [specification published in 2002.]
• Selectors (:lang, :nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .]
• XHTML 1.0 [specification published in 2000.]
• CSS2 (@font-face) [specification published in 1998.]
• CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
• CSS3 Color (rgba(), hsla(), ...) [specification published in 2003.]
• CSS3 UI ('cursor') [specification published in 2004.]
• data: URIs [specification published in 1998.]
• SVG (SVG Animation, SVG Fonts, ...) [specification published in 2001.]

As you can see, the majority of the Acid3 test is comprised of behaviour described in specifications published years ago, with a substantial portion of them over five years old and some over a decade old.

CSS3 intoduces many changes,

Actually, CSS 3 is not a single specification, but a group of

The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.

Let's do exactly what you suggest, and "RTFM". From the Acid3 page at webstandards.org, with links to the specifications and dates added by me:

Here is the list of specifications tested:

• DOM2 Core [specification published in 2000.]
• DOM2 Events [specification published in 2000.]
• DOM2 HTML [specification published in 2003.]
• DOM2 Range [specification published in 2000.]
• DOM2 Style (getComputedStyle, ...) [specification published in 2000.]
• DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
• DOM2 Views (defaultView) [specification published in 2000.]
• ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
• HTML4 (<object>, <iframe>, ...) [specification published in 1997.]
• HTTP (Content-Type, 404, ...) [specification published in 1999.]
• Media Queries [specification published in 2002.]
• Selectors (:lang, :nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .]
• XHTML 1.0 [specification published in 2000.]
• CSS2 (@font-face) [specification published in 1998.]
• CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
• CSS3 Color (rgba(), hsla(), ...) [specification published in 2003.]
• CSS3 UI ('cursor') [specification published in 2004.]
• data: URIs [specification published in 1998.]
• SVG (SVG Animation, SVG Fonts, ...) [specification published in 2001.]

As you can see, the majority of the Acid3 test is comprised of behaviour described in specifications published years ago, with a substantial portion of them over five years old and some over a decade old.

CSS3 intoduces many changes,

Actually, CSS 3 is not a single specification, but a group of

If so, that would be a very bad choice indeed!
In the absence of a MX record, a correctly functioning SMTP client must treat an A record like an implicit MX record with preference 0. Go read RFC2821, section 5 - it's all spelled out there.

May I suggest reading RFC 2606, Reserved Top Level DNS Names. There is example.com for a reason.

http://tools.ietf.org/html/rfc2606

You do *not* needs DHCP to get DNS addresses under IPv6. See http://tools.ietf.org/html/draft-ietf-dnsop-ipv6-dns-configuration-06 -- the RA method is site-local not link-local, so it works across routers if they are configured correctly. And once you have DNS you can configure everything else via SRV records.

On the "MAC addresses change" note, an ease solution is to simply change the MAC address of the replacement card to match the old one. Since the old one is no longer in use there's no conflict, and then there's no external change to be made anywhere on the network. You've have to type the new MAC address in somewhere to get the DHCP server to hand out the same address, so you might as well just do it locally.

Likewise DHCP is hardly the only option for reverse-DNS registration; it doesn't take a whole lot of scripting to submit the local hostname to some remote service that can update DNS. We've decided the DHCP server is a good place to do this, because it knows both those items and is centrally administered, but it's certainly not complicated to replicate with other mechanisms.

Now, you may prefer to do things via DHCP, and I wouldn't necessarily blame you, but it's not strictly necessary, and for many simple networks -- say home routers -- there's no reason for DHCP at all.

I assume you mean '85? RFC 959 But even by then leisure suits were on the way out - except for sierra games ;)

On a side note, why is the next leisure suit larry game only for the PS3, XBOX, but not the wii. Talk about missing an opportunity for using the wiimote for gameplay...

http://tools.ietf.org/html/rfc959 refers to the 1985 FTP spec, itself obsoleting 1980's http://tools.ietf.org/html/rfc765, so "disco-era" would be fair.

http://tools.ietf.org/html/rfc959 refers to the 1985 FTP spec, itself obsoleting 1980's http://tools.ietf.org/html/rfc765, so "disco-era" would be fair.

I think you mean the current generation of FTP was created in 1985 not 1995.

See http://tools.ietf.org/html/rfc959

But that was not the first RFC published on FTP the first was in 1971

http://tools.ietf.org/html/rfc114

Here is a history of FTP:

The first FTP standard was RFC 114, published in April 1971, before TCP and IP even existed. This standard defined the basic commands of the protocol and the formal means by which devises communicate using it. At this time the predecessor of TCP (called simply the Network Control Protocol or NCP) was used for conveying network traffic. There was no Internet back then. Its precursor, the ARPAnet, was tiny, consisting of only a small group of development computers.

A number of subsequent RFCs refined the operation of this early version of FTP, with revisions published as RFC 172 in June 1971 and RFC 265 in November 1971. The first major revision was RFC 354, July 1972, which for the first time contained a description of the overall communication model used by modern TCP, and details on many of the current features of the protocol. In subsequent months many additional RFCs were published, defining features for FTP or raising issues with it. RFC 542, August 1973, the FTP specification looks remarkably similar to the one we use today, over three decades later, except that it was still defined to run over NCP.

After a number of subsequent RFCs to define and discuss changes, the formal standard for modern FTP was published in RFC 765, File Transfer Protocol Specification, June 1980. This was the first standard to define FTP operation over modern TCP/IP, and was created at around the same time as the other primary defining standards for TCP/IP.

RFC 959, File Transfer Protocol (FTP), was published in October 1985 and made some revisions to RFC 765, including the addition of several new commands, and is now the base specification for FTP. Since that time a number of other standards have been published that define extensions to FTP, better security measures and other features. (Some of these are discussed in the general operation section in the appropriate places.)

http://www.primusweb.com/fitnesspartner/library/activity/gf_guide1.htm

I think you mean the current generation of FTP was created in 1985 not 1995.

See http://tools.ietf.org/html/rfc959

But that was not the first RFC published on FTP the first was in 1971

http://tools.ietf.org/html/rfc114

Here is a history of FTP:

The first FTP standard was RFC 114, published in April 1971, before TCP and IP even existed. This standard defined the basic commands of the protocol and the formal means by which devises communicate using it. At this time the predecessor of TCP (called simply the Network Control Protocol or NCP) was used for conveying network traffic. There was no Internet back then. Its precursor, the ARPAnet, was tiny, consisting of only a small group of development computers.

A number of subsequent RFCs refined the operation of this early version of FTP, with revisions published as RFC 172 in June 1971 and RFC 265 in November 1971. The first major revision was RFC 354, July 1972, which for the first time contained a description of the overall communication model used by modern TCP, and details on many of the current features of the protocol. In subsequent months many additional RFCs were published, defining features for FTP or raising issues with it. RFC 542, August 1973, the FTP specification looks remarkably similar to the one we use today, over three decades later, except that it was still defined to run over NCP.

After a number of subsequent RFCs to define and discuss changes, the formal standard for modern FTP was published in RFC 765, File Transfer Protocol Specification, June 1980. This was the first standard to define FTP operation over modern TCP/IP, and was created at around the same time as the other primary defining standards for TCP/IP.

RFC 959, File Transfer Protocol (FTP), was published in October 1985 and made some revisions to RFC 765, including the addition of several new commands, and is now the base specification for FTP. Since that time a number of other standards have been published that define extensions to FTP, better security measures and other features. (Some of these are discussed in the general operation section in the appropriate places.)

http://www.primusweb.com/fitnesspartner/library/activity/gf_guide1.htm

Disco-era? It was first implemented in 1995.

Then why were people writing about it in 1971?
http://tools.ietf.org/html/rfc114

First off, since when is a 'URL' considered a transport mechanism rather than syntax for specifying a transport mechanism and location?

What about a URL to make donations to a terrorist organization? What about a URL where, every time you go there, it sets off an automated script that pulls the trigger on a shotgun and shoots an adorable kitten in the face?

These are bad examples because in order to actually do the harmful act, you either have to POST information (something distinctly different from retrieving the URL), or the other party has to subvert the HTTP protocol (which you can't reasonably be considered responsible for). Straight from RFC 2616:

The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

Or think about it this way: whenever you visit a web page, the author of that web page can induce you to request any URL they like automatically. Chances are, you won't even be aware of it. Still think it's a good idea to hold people accountable for merely visiting a URL?

You can find out more about the repeaters here. Problem is, mesh networking protocols aren't well suited for covering an entire city. The protocol used by OLPC is based on AODV, which uses flooding for route discovery. That's efficient if the mesh is sparse and there are a few long-lived connections, but inefficient if the mesh is dense or there's a lot of traffic. You could almost say that if mesh networking is a solution in search of a problem, the problem it's been searching for is two kids under a tree in the middle of the desert. ;-)

Not quite. If you look at RFC 2119, you will notice that each of the words has its precise definition. So for instance, not implementing a "SHOULD" still doesn't break standards compliance. Full stop.

Take a look at http://tools.ietf.org/html/draft-irtf-ipnrg-arch-01 and check out cool ASCII-art figures about example topology. (Basically, they are thinking about adding a "bundle layer" between IP and TCP to make TCP work without timeouts becoming issue..)

Take a look at http://tools.ietf.org/html/draft-irtf-ipnrg-arch-01 and check out cool ASCII-art figures about example topology. (Basically, they are thinking about adding a "bundle layer" between IP and TCP to make TCP work without timeouts becoming issue..)

> There were several articles.

Perhaps you can link to them for us since only one was linked in the original article summary.

>>> I'm shocked to see FreeBSD claiming to be the reference implementation of SCTP. It's been in Linux for years.
> FreeBSD didn't beat Linux to a shipping kernel for SCTP.

Again, the first to ship it with the default kernel. Again, clearly stated in the article.

I finally found the reference to the "reference implementation" retardation you brought up in the FreeBSD 7.0 release notes, here, look at this:

http://www.ietf.org/mail-archive/web/tsvwg/current/msg00245.html

this is the reference implementation of SCTP. It was developed on FreeBSD and it's now part of the default FreeBSD kernel. Please note the date: 2001 Mar 17. Yeah, FreeBSD has had an SCTP implementation for six years; made six months after the original SCTP RFC was released. For fuck's sake, the guy who did the SCTP FreeBSD implementation wrote the fucking RFC for SCTP:

http://www.ietf.org/rfc/rfc2960.txt

So yes, while it wasn't stated as such and you merely inferred it incorrectly (repeatedly), FreeBSD has even had an SCTP implementation longer than Linux has.

> There are more Linux distributions than you can count.

"My OS has more penises than your OS! Heh, an OS with one penis! Wow. Weird!"

> Also, let me introduce you to Gentoo and Linux From Scratch. ...OK? Why? What the fuck does this have to do with anything?

>>> Heh. A "large number of CPUs" is 8+ to you. Linux is struggling to handle 16384. (yes, SMP-style NUMA with 1 OS image)
> I used quotation marks for a direct quote. The article's author thought that 8+ was large. For some time now, you could get 8 CPUs in an totally standard consumer-targeted Apple machine.

Again, that article wasn't linked, and who is the "you" in 'a "large number of CPUs" is 8+ to you?' Hey, see what I did there? I used quotation marks, and it was using a previously made statement, in addition to being relevant to the argument at hand.

> There were several articles.

Perhaps you can link to them for us since only one was linked in the original article summary.

>>> I'm shocked to see FreeBSD claiming to be the reference implementation of SCTP. It's been in Linux for years.
> FreeBSD didn't beat Linux to a shipping kernel for SCTP.

Again, the first to ship it with the default kernel. Again, clearly stated in the article.

I finally found the reference to the "reference implementation" retardation you brought up in the FreeBSD 7.0 release notes, here, look at this:

http://www.ietf.org/mail-archive/web/tsvwg/current/msg00245.html

this is the reference implementation of SCTP. It was developed on FreeBSD and it's now part of the default FreeBSD kernel. Please note the date: 2001 Mar 17. Yeah, FreeBSD has had an SCTP implementation for six years; made six months after the original SCTP RFC was released. For fuck's sake, the guy who did the SCTP FreeBSD implementation wrote the fucking RFC for SCTP:

http://www.ietf.org/rfc/rfc2960.txt

So yes, while it wasn't stated as such and you merely inferred it incorrectly (repeatedly), FreeBSD has even had an SCTP implementation longer than Linux has.

> There are more Linux distributions than you can count.

"My OS has more penises than your OS! Heh, an OS with one penis! Wow. Weird!"

> Also, let me introduce you to Gentoo and Linux From Scratch. ...OK? Why? What the fuck does this have to do with anything?

>>> Heh. A "large number of CPUs" is 8+ to you. Linux is struggling to handle 16384. (yes, SMP-style NUMA with 1 OS image)
> I used quotation marks for a direct quote. The article's author thought that 8+ was large. For some time now, you could get 8 CPUs in an totally standard consumer-targeted Apple machine.

Again, that article wasn't linked, and who is the "you" in 'a "large number of CPUs" is 8+ to you?' Hey, see what I did there? I used quotation marks, and it was using a previously made statement, in addition to being relevant to the argument at hand.

Clearly, he hasn't read that the current Internet has a provision for this: the Evil Bit set in the IP header, as specified in RFC 3514, published 1 April 2003.

I agree 100% that arbitrary barriers are worthless. More often then not, it's the developers who believe so (I consider myself a SW Engineer not a Developer), who don't get work done, because they can't just evolve around problems as they come up.

Developer -> I've only ever programmed in (Insert Language Here), but I'm really good at it.
SW Engineer -> I use C for my embedded projects because of code size and performance, mostly C# for my windows applications because I get to re-use all these great MS libraries, and Frankly pretty much any time I need a quick and dirty tool for generating test scripts, or helping with Cadence I use PERL.

Look for people who evolve themselves to meet a problem, rather than try to make the problem fit their system. I'd say more often then not these people will have excelled time after time in seemingly unrelated jobs, versus the people who continue doing the same thing forever, 'til they become an obsolete commodity and are only good for complaining about outsourcing.

Most of the people I consider superstars are really just regular old problem solving engineers. These people can take any problem, and either find or build components to make it happen. I've known a *FEW* superstars who were ONLY software engineers. I'm sure that even those guys need some variety and support too though.

Honestly I'd say what's harder is retaining people like this, because they CAN always get another great job. It's probably more important that you give these people interesting, and varied work, make sure you don't overload them as they're already the most productive piece of your puzzle, and give them a strong supporting cast they can leverage to be even more productive.

At least that's what I think makes me a superstar, and has exemplified the ones I've worked with before. What makes me feel like I can say these things?

Some of my background:

Started at AMCC as an intern, basically a lab tech.
4 years at Qualcomm in my early days doing test.
http://vesicle.nsi.edu/nomad/segway/ -> Neural Simulation/Segway based Soccer Playing Platform
http://natural.uchicago.edu/~tgal/ -> Parsing and Analysis Tools for Affymetrix Gene Array Arabadopsis Sequencing
http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-15.txt -> IETF Speech Recognition Protocol
Development from scratch and evolution of a couple of medical devices (Triage Wireless/Dexcom)

Currently I'm a couple years deep working at a semiconductor startup, where I've done some Digital Blocks for our ASICs, Design and Layout of our basic Electronics, and ALL of the embedded firmware, along with PC Software for in house, and external use. I truly believe, and have yet to be disproved, that I can just about solve any problem. Usually it's the time -vs- desire for elegance that's my weakness. I guess that's what management is for....right?

Go read the thread on NANOG. Or read the timeline here: http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

The way this happened is the result of a fundamental weakness in BGP. A more specific prefix will trump a less specific one, so anyone who has a valid peer can advertise a more specific route and hijack IP space. This is frequently used by Cybercriminals to squat on unused IP space in larger netblocks.

There have been proposals to address this issue for some time. Maybe, now that a major site has fallen victim, something will actually be done about it.

Of course, we could solve the problem the way it was when the Internet was first designed: only allow trusted entities to connect at all. IMNSHO, if the Islamic world don't want to be in the 21st century, that's their choice, but they can't have their cake and eat it too. Unless and until they agree to the basic principles of the Internet: freedom of association and speech, they shouldn't be allowed to connect at all.

This was discussed yesterday, but somehow the mods didn't control the discussion degenerating into a debate about circumcision.

Surely the IETF could come up with a "piracy bit" to go with the evil bit?

X.509 v3 Extensions (specifically the subjectAltName). RFC 3280 has all the gory the details.

Or we can delay it a few more years if we all start implementing Server Name Indication (SNI), as described in section 3.1 of the http://www.ietf.org/rfc/rfc3546.txt. This would let hosting companies share 1 IP with several domain names and still be able to use https because the certs would have multiple domain names. It should be much cheaper (only certs are extra cost) and requires almost no hardware changes (some ssl accelerators might need upgrades).

Yeah, we always fall back on the government to help us out when us nerds aren't satisfied with how capitalism is driving the technological trends that need to happen.

But let's not forget those that went before us. Jun-ichiro Hagino, better known as Itojun, was one of the first researchers that was pushing for IPv6 since as long as I can remember (at least 2001). On top of that he was developing specifications for it and working through the BSD code to make it one of the first operating systems fully capable of being IPv6 compliant--starting a trend that needs to happen in more operating systems sooner. He even started documenting draft APIs to get developers thinking about how this would work inside software.

And then he died in a car accident at age 37. It's funny how you don't appreciate their work until they're dead. Almost like a painter or author.

Although many still carry on his work, the saddest part is that all his efforts to bring awareness to everyone about IPv6 may fall into the responsibilities of the government or, worse, capitalism.

http://www.ietf.org/rfc/rfc3675.txt

>But it can be used as one.

There is not a one-to-one mapping of DNS entries to IP addresses. I can mirror the entire .xxx TLD in a .com with relatively little work if I choose to do so and completely invalidate your scheme.

The problem is that the people who want to use .xxx want an *exclusive* system, something that can be used to filter out content. DNS cannot be used to do that. Really.

There are lots of other reasons why .xxx is a really appallingly stupid idea. San Francisco and Houston can't agree on decency standards and you want the entire world to agree? It doesn't deal with anything other than host-level content categorization, provides only a single bit "adult" or "non-adult", and has all kinds of other flaws that have been far better technically addressed in the form of [ICRA](https://secure.wikimedia.org/wikipedia/en/wiki/Internet_Content_Rating_Association).

There has been plenty of input from the techies on this.

You want to set up an alternative root with an .xxx TLD, knock yourself out. It's going to be ignored because it's a bad idea.

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

Or just implement RFC 3514. That would solve so many problems in addition to porn.

But by whom is the use legitimate? Most residential Internet access plans offered by the last-mile duopoly have a stipulation that residential subscribers MUST NOT[1] "run a server" on the connection. So even if it isn't an infringement on anyone's copyright, seeding a torrent might still be an infringement on the exclusive rights of the owner of the last-mile physical medium.

[1] RFC 2119

A couple of smallish corrections:

The SSP specification is under active development in the IETF DKIM Working Group. There is a much newer version of the spec here, but the spec is still evolving.

The public key is looked up using the "s" (selector) and "d" (domain) attributes of the signature. "c" specifies the canonicalization algorithm (used to deal with trivial modifications such as spacing to the body).

But generally, very good points...

But I am unaware of any mechanism to produce a "revocation certificate" or how or why you would issue one in advance of a certificate being revoked. Without the signature of the CA (or the indirect CRL) there's no way to "revoke" a certificate.

Sure, if your Certificate Authority's administrator is corrupt, you might get hosed. That's why you need secured access to the equipment, and a strong set of policies to protect it.

If your an org that sends out emails from a 3rd party from time to time, (IE, surveys, or other crap), then you will have issues with SPF.

Both SPF and DKIM have problems with this kind of thing. With SPF, you need to include these third parties in your SPF record (possibly using the SPF "include:" mechanism). As you mentioned, with DKIM, you have to send them a key.

I've also heard about relaying problems in large companies, with decentralized email, ie, each divison or site has its own mail server.

Yes, tracking down all your mail servers is a huge problem for large organizations. SPF can help identify these sources by means of a "tracking exists: mechanism". This can then be used to help add IP addresses to SPF records or distribute keys for DKIM.

For some reason that seems familiar.

Speaking of technical editing, why is it so common to see crap like yourdomain in books? The .example TLD along with example.com etc. have all been reserved for this purpose by RFC 2606 so examples don't conflict with domains that are already in use. Isn't this the sort of thing a technical editor, as opposed to a normal editor, should pick up on? It just reminds me of the stupid novel and film writers that title their works with domain names already in use by others. It's just not necessary.

Will this research improve applications following RFC 2549?

You have no idea how long I waited to try to use that within context :)

Given SPAM filtering on news groups and other pre-TCP/IP messages

News groups are pre-TCP/IP? That's funny, as TCP/IP dates from 1974 when RC 675 was specified and V4, RFC 793 specified in 1981. Usenet was established in 1980, before 1981 but after 1974.

Given SPAM filtering on news groups and other pre-TCP/IP messages

News groups are pre-TCP/IP? That's funny, as TCP/IP dates from 1974 when RC 675 was specified and V4, RFC 793 specified in 1981. Usenet was established in 1980, before 1981 but after 1974.

A big part of the problem is that the iPhone is polling for mail every 'x' minutes, rather then using the over-10-year-old IMAP IDLE command to receive updated from the server via a push.

This method requires one packet every 29 minutes while idle (to update the server that the client is still IDLEing and to avoid timing out), but otherwise, data is only transmitted when something has actually changed.

On my Treo 680, this nearly doubles your standby-with-mail-client-online (but no calls, no TXTs, no email sent or received) time, vs regular polling (which, in the iPhone's case, is a fairly substantial IMAP query)

Mail still gets sent in-the-clear, in plaintext.

The realm is only half of the identifying element - the URL requesting authentication is the other half. For basic authentication (RFC 2617, section 2), the realm value is only for the server sending it; if another server (identified typically by [ http/https, hostname, port ]) sends me a WWW-Authenticate header with the same realm name specified, for the purposes of authentication it is a different realm. In digest authentication (section 3), it is possible to have credentials go across multiple servers, but such servers have to be specified in the initial WWW-Authenticate header in a "domain" parameter; otherwise, the authentication is again only available to the server sending the WWW-Authenticate header in the first place.

Ultimately, unless your system, DNS server, proxy server (if you're using one), gateway, or the target server, have been broken into, obtaining the credentials for any given realm is going to be difficult; if your system has been broken into, this is pointless because they could just as easily install a keylogger to capture the authentication information as it's being entered; if your gateway has been broken into, then unless you're performing all authenticated transactions over HTTPS and/or not using HTTP Basic authentication, the information is going across there in cleartext anyway, and tcpdump is all that's needed to extract it. Since the proxy server tends to exist at the gateway level anyway, the same issues apply there. As far as the target server goes - you can either capture the authentication info there, or, since you've got permissions to do anything the webserver is capable of, including generally accessing the authentication DB, just grab the authentication information and be done with it.

So... good luck at attempting to reuse the exact realm of another server - since, for the purposes of comparing authentication realms, the realm name is little more than a token which identifies a given protection space on a single server (or multiple explicitly specified servers in HTTP Digest, but that's still explicit).

If this DRM system used a similar scheme as RFC 3514. This RFC has been extensively discussed before in Slashdot. A DRM implementation based on the same concept would keep all the open source community happy, while providing the standardization the EU recommends.