I said "stop". That patch is an option that users can enable or disable. And lots of users will likely disable it so they can run the next silly game, or coke commercial, or screen saver.
Do you really think we don't research these things? Do some research into the company before you lambast us.
Well, as other posters have pointed out, you need to set the execute bits. That's always going to be a task my mother would shy away from. Of course that may also be something that prevents widespread adoption of Unix on the desktop:-)
I work for a managed security provider and we stopped this using heuristics for all our customers. It's growth rate has been phenomenal, considering it doesn't even use any hacks - it's just a stupid social engineering virus! It was very funny listening to our anti-virus guy on the phone to reporters saying "We've stopped 4000 in the last two hours. No wait, 5000.... oh, and now 6000".
The problem is there's *nothing* Microsoft can do to stop this sort of virus, as long as they allow execution of files direct from their email client, and honestly I can't see that stopping (and neither can the people where I work, which they're quite happy about:-)
I do worry for apps like this on Linux though, as email clients become able to execute attachments. But the benefit is that Linux doesn't assume things based on file suffix, but on their actual mime type. However, that still leaves a possible vulnerability to mime type spoofing, perhaps.
Aaah, but that's NOT true. For starters XML-RPC uses an EXTREMELY stripped down XML for encapsulation, using no attributes. SOAP requires an XML parser capable of understanding attributes and namespaces.
So that covers just about every XML parser in existance then.
Furthermore XML-RPC is far easier to implement as a CGI-type application, because it requires no information from the HTTP headers. SOAP requires a SOAP-Action header to tell it what to do.
Eh? This will be in the HTTP_SOAP_ACTION environment variable with every CGI 1.1 compliant environment.
SOAP and XML-RPC are only trivial if your language happens to have a compliant (but not quiet, because these do not use valid XML documents) XML parser library too. And those aren't as common as some people think.
I think that's pretty specious at best. XML parsers are very easily obtained with any language, and most languages have some sort of SOAP and XML-RPC support, so you can pick and choose.
The point being (which you seem to have missed), XML-RPC is as easy as SOAP from the user's perspective, not from the developer's perspective.
The problem with all this SOAP vs XML-RPC nonesense is that it avoids the real issue: very few people have to write a SOAP or XML-RPC library for any language. Using SOAP in most languages is trivial. Same for using XML-RPC. So let's get over the arguments about how the XML-RPC spec is easier to read - partly it's easier to read because it's so damned inconsistent! Both protocols are equally easy to use. And that's the important point.
That C component has to go into the Apache server (and run with server privileges, with all that implies, like a potential for buffer overflow attacks) for mod_perl programs to use it.
Complete and utter BS.
What are "server privileges" ? Everything in apache runs under the nobody user (or configurable).
What potential for buffer overflow attacks? Show me one.
The component does *not* have to go into the Apache server for mod_perl programs to use it. Not even slightly. If that were the case, DBI would be unusable from mod_perl, wouldn't it? No-siree, the C component (expat) was included in Apache to support mod_dav. They modified expat slightly (and called it expat-lite), and thus we had symbol conflicts, and the wrong code being executed, and BOOM. So now Apache 1.3.22 uses the DSO expat, same as XML::Parser does, and the problems are gone.
Someone please mod me up or him down. Facts can be checked in the mod_perl and mod_perl-dev list archives.
About the only exception I can think of to this general rule, where filename extensions are important are for the web
If that were true, you wouldn't be able to view this web page - your perl interpreter would try and read it instead. The web uses MIME types, passed in the headers.
I also wrote an article on the XML format for XML.com which you can find here.
It was written before they did the whole Zip thing (though I do mention the zipping in the article), but some of the pointers should still be valid for anyone looking to be able to read the format.
Maybe at it's current service pack state, but holy shit did it take them a long time and a lot of service packs to get it into that state! In fact, the original release of NT4 was a bag of shite - constantly rolling over and dying. Not until service pack 3 did it become stable. And then we had service pack 4 - what a joy that was *NOT!*.
Three: There next big focus area is the laptop market. This will be the only place with "new" AMD processors. Most likely people will see more 1.0 GHz+ AMD based laptop systems soon.
Great! Time to start selling heat resistant lap-covers.:-)
Think if the ketchup analogy that business types talk about. Heinz is the default ketchup brand. Why? Well they stick bunch of well known ingredients into a bottle, put a well known label on it, and sell it for a reasonable price. Sure other brands might be a little cheaper, but not by a whole lot, and Heinz gets to keep their market share even though they aren't doing anything particularly special. It works as long as they don't raise the price too high . If Heinz were, say, double the price of their nearest competitor then people would start to take notice and try the alternatives. Once they got to know some other brands Heinz would have a really hard time winning those customers back.
Actually I disagree.
Heinz ketchup tastes much better than XP CDs. And it's cheaper.
This is not just a Code-Red like virus, it's also a mass mailer (like SirCam). This is going to be bad for the unprotected, and worse for the protected, because we suffer the clawback after effects.
Disclaimer: I was one of the two tech editors for this book.
We decided not to include schemas coverage because the Nutshell books cover not just a description of the technologies, but also best practices. Schemas best practices are only just becoming clear, as can be seen on the xml-dev mailing list. Along with that, Schemas were not yet ratified when the book went to tech review, so we could have only covered an old draft.
Rest assured though, W3C Schemas (and if I can persuade Elliotte, RELAX too) will be covered in the second edition, which I believe is being worked on already.
Re:Online XML references?
on
XML in a Nutshell
·
· Score: 3, Informative
Try Zvon. http://www.zvon.org. They are a great site that is regularly updated.
PS: I was a tech editor for XML in a Nutshell, so it's really cool to see it reviewed here:-)
It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.
Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.
These are mantras that I've heard regularly from Lisp and functional language users, but I've yet to see them thoroughly backed up.
Perl coders use functions *all* the time. Even OO method calls are implemented as simple functions. If you need named parameters, use a hash or hashref. There are even modules that validateparameters so you can have a call signature.
As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list. Now, I don't know if lisp does lazy evaluation, if so that's something Perl doesn't do, and would be a very valid point against it. But you didn't mention that...
Seriously, I'm not trying to flame. I'm geniunely curious about these points.
Both have infra red. Just enable infra red reception on your phone (mine is at "Menu/Infra Red") send out your address book from your Palm pilot, and point the two at each other.
Seriously this works. It uses vCard IIRC so the format is compatible between the two, and it just works. At least it did between my Nokia 8210 and my Palm V.
Oh, you don't have infra red??? Sorry, maybe someone else will answer:-)
There's a lot of validation done on date strings (i.e. check it's 9 digits). For example, there's a lot of code out there that creates filenames based on this 9 digit string, and then there's apps that load up those files. There's also cookies that get set based on the epoch seconds. Any sanity checking that looks for a 9 digit integer is going to go bang. I've come across some of that code where I work. I'm sure other people will too, and it's all too easy to ignore due to the lack of hype surrounding the 1e9s bug.
Notice how microsoft's products are all verbs? Internet Explorer, Access,excel, etc.
How are "Word" and "Windows" verbs?;-)
Re:web services, big deal
on
Shirky On P2P
·
· Score: 2
Here's how slashdot disseminates its feeds in XML and RDF and HTML: you grab it from a URL, and the webserver shovels it at you, blithely ignorant of the semantic meaning of the bits it's transferring around.
Welcome to web services.
There's a lot of possible layers there. Yes you can use SOAP and WSDL if you want to, but at it's simplest layer you're providing a service of information (rather than HTML) over the internet (doesn't have to be over HTTP). Slashdot is providing a simple web service in its RSS feed. I think you'll see a lot more people coming to the conclusion that they don't need SOAP and WSDL. Straight XML served over HTTP perhaps with parameters in the querystring is an excellent way to deliver web services.
I have a paper on why this is an excellent way to do things that I gave at the open source conference, but my web server is offline right now and won't be back up for about 4 weeks (due to the wonderfulness of British Telecom). When it's back, you'll be able to find it at http://axkit.org/docs/presentations/tpc2001/
Now slashdot moderators, please read some damned XML books before moderating crap like the above up. I recommend XML in a Nutshell, which I was a tech editor for.
Once again: To use a validating parser you need the DTD, of course. But the W3C makes no provision where to get this DTD!
The Declaration inside a RDF-File for example is containing a xmlns-Attribute. That is XML-_N_ame_s_pace. Nothing
more. See for example the declaration in http://slashdot.org/slashdot.rdf:
OK:
$ g-request http://slashdot.org/slashdot.rdf
<?xml version="1.0" encoding="ISO-8859-1"?><rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax -ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/"> ...
Sorry, no cigar. This does not contain a DOCTYPE declaration. Try an RSS 0.91 file, e.g. from xmlhack.com:
You can not run a validating parser solely on this. Because the URIs given above are in fact (what you appearently do not
want to understand) only Namespace, and not a reference to the DTD.
No, you cannot run a validating parser solely on the first one because it uses XML namespaces! Try the RSS 0.91 file format. That's what we're talking about here.
There is no defined way to automatically determine where to get the DTD. You need to get it yourself and supply it to your
validating Parser.
I, and the XML spec, beg to differ. I quote:
[Definition: The SystemLiteral is called the entity's system identifier.
It is a URI reference (as defined in [IETF RFC 2396], updated by [IETF
RFC 2732]), meant to be dereferenced to obtain input for the XML
processor to construct the entity's replacement text.]
How do you dereference HTTP URI's? Well shock horror you use the HTTP protocol!;-)
I've given the XSL(T)-Example. The XSL(T)-Declaration contains a URI as well.
No, it does NOT. There is no Declaration, only a start element. The reason being that XSLT uses XML namespaces, and namespaces aren't compatible with DTDs (well, they *mostly* aren't compatible - but I'll leave it to a book like XML in a Nutshell to explain the finer details).
But the DTD is not there, only a
information by the W3C, that this is the XSL(T)-Namespace. After all you may imagine that the W3C knows what it does.
Correct, the W3C does know what it does. The document pointed at by the namespace (which as you correctly, but confusingly point out, doesn't actually need to exist) at the W3C site is in RDDL. Go to XML.com to find out what RDDL is. (actually it might not yet be in RDDL, because the W3C is only slowly moving over to RDDL. But the Schema namespace *does* point to a RDDL document, and this is a sign of things to come).
A
valid XSL(T)-Document does not contain any reference about where to get the DTD.
That's because XSLT can't use DTDs, because it uses XML namespaces.
This was specifically intended so, as
the Locations of DTD can change, as the example here shows us.
Actually the reason namespaces chose not to have anything at the URI is because they didn't have a namespace compatible schema system in place at the time, and so nobody could agree what to put there. Now the people on the XML-Dev mailing list have agreed on putting RDDL documents there.
So you are still wrong. Having the DTD disappeared from Netscapes site DOES NOT make problems to validating parsers by
default. Just obtain the DTD elsewhere and feed it into your parser.
That's possible if you implement a custom URI resolver, but barely anybody does that because it's not the right way to go about fixing the problem (which is to use a catalog system based on the PUBLIC identifier instead).
But this IS NOT A PROBLEM BY CONCEPT. The W3C recognized that it can be virtually impossible to maintain a ever
lasting repository for a DTD, and therefore does not urge you to make any links to your DTD. The URI in the Declaration is
only Namespace, and you don't even need to put a Webpage there. The W3C itself had not webpages at there URIs at the
beginning. Only after having too much people who do not understand (like you) complaing the added this short text. You can
use mailto:bla@fasel or gopher:.. or telnet: or anyother unique URI you might imagine. Just make it unique for a given DTD.
You're talking about namespaces again, not DTD's. Please go and buy a good book on XML (such as XML in a Nutshell, which I was one of two tech editors for) that will help clear up your confusion.
We're not talking about namespaces here. We're talking about DTDs, particularly the SYSTEM identifier, which is meant to be fetchable (it even says so in the XML spec).
RSS 0.91 isn't even namespace aware.
Plus, you say "for simply _using_ RSS you won't even need the DTD". That's only *mostly* true, unfortunately. The RSS 0.91 DTD contains all the HTML entity references that are commonly used in RSS 0.91 files, and an XML parser will choke without these being defined somewhere (and that somewhere happens to be the DTD) (well actually a non validating parser can just ignore the entities (providing they are syntactically correct), but then you'd end up with strange looking content).
Slashdot Mirror
I said "stop". That patch is an option that users can enable or disable. And lots of users will likely disable it so they can run the next silly game, or coke commercial, or screen saver.
Do you really think we don't research these things? Do some research into the company before you lambast us.
Well, as other posters have pointed out, you need to set the execute bits. That's always going to be a task my mother would shy away from. Of course that may also be something that prevents widespread adoption of Unix on the desktop :-)
The problem is there's *nothing* Microsoft can do to stop this sort of virus, as long as they allow execution of files direct from their email client, and honestly I can't see that stopping (and neither can the people where I work, which they're quite happy about :-)
I do worry for apps like this on Linux though, as email clients become able to execute attachments. But the benefit is that Linux doesn't assume things based on file suffix, but on their actual mime type. However, that still leaves a possible vulnerability to mime type spoofing, perhaps.
- Aaah, but that's NOT true. For starters XML-RPC uses an EXTREMELY stripped down XML for encapsulation, using no attributes. SOAP requires an XML parser capable of understanding attributes and namespaces.
So that covers just about every XML parser in existance then.- Furthermore XML-RPC is far easier to implement as a CGI-type application, because it requires no information from the HTTP headers. SOAP requires a SOAP-Action header to tell it what to do.
Eh? This will be in the HTTP_SOAP_ACTION environment variable with every CGI 1.1 compliant environment.- SOAP and XML-RPC are only trivial if your language happens to have a compliant (but not quiet, because these do not use valid XML documents) XML parser library too. And those aren't as common as some people think.
I think that's pretty specious at best. XML parsers are very easily obtained with any language, and most languages have some sort of SOAP and XML-RPC support, so you can pick and choose.The point being (which you seem to have missed), XML-RPC is as easy as SOAP from the user's perspective, not from the developer's perspective.
The problem with all this SOAP vs XML-RPC nonesense is that it avoids the real issue: very few people have to write a SOAP or XML-RPC library for any language. Using SOAP in most languages is trivial. Same for using XML-RPC. So let's get over the arguments about how the XML-RPC spec is easier to read - partly it's easier to read because it's so damned inconsistent! Both protocols are equally easy to use. And that's the important point.
HTTP 1.1 has most of what you're looking for. And with the DAV extensions you can get the equivalent of directory listings too.
That C component has to go into the Apache server (and run with server privileges, with all that implies, like a potential for buffer overflow attacks) for mod_perl programs to use it.
Complete and utter BS.
What are "server privileges" ? Everything in apache runs under the nobody user (or configurable).
What potential for buffer overflow attacks? Show me one.
The component does *not* have to go into the Apache server for mod_perl programs to use it. Not even slightly. If that were the case, DBI would be unusable from mod_perl, wouldn't it? No-siree, the C component (expat) was included in Apache to support mod_dav. They modified expat slightly (and called it expat-lite), and thus we had symbol conflicts, and the wrong code being executed, and BOOM. So now Apache 1.3.22 uses the DSO expat, same as XML::Parser does, and the problems are gone.
Someone please mod me up or him down. Facts can be checked in the mod_perl and mod_perl-dev list archives.
About the only exception I can think of to this general rule, where filename extensions are important are for the web
If that were true, you wouldn't be able to view this web page - your perl interpreter would try and read it instead. The web uses MIME types, passed in the headers.
Not just little tools.
Matt also wrote Dice C, which was a rocking good compiler, though admitedly not quite up to par with SAS's tool suite.
Once the Amiga market died, Matt gave Dice away to the community under the BSD license. You can still find it on Aminet today.
I also wrote an article on the XML format for XML.com which you can find here.
It was written before they did the whole Zip thing (though I do mention the zipping in the article), but some of the pointers should still be valid for anyone looking to be able to read the format.
NT4 is the best OS MS ever made
Maybe at it's current service pack state, but holy shit did it take them a long time and a lot of service packs to get it into that state! In fact, the original release of NT4 was a bag of shite - constantly rolling over and dying. Not until service pack 3 did it become stable. And then we had service pack 4 - what a joy that was *NOT!*.
Three: There next big focus area is the laptop market. This will be the only place with "new" AMD processors. Most likely people will see more 1.0 GHz+ AMD based laptop systems soon.
:-)
Great! Time to start selling heat resistant lap-covers.
Think if the ketchup analogy that business types talk about. Heinz is the default ketchup brand. Why? Well they stick bunch of well known ingredients into a bottle, put a well known label on it, and sell it for a reasonable price. Sure other brands might be a little cheaper, but not by a whole lot, and Heinz gets to keep their market share even though they aren't doing anything particularly special. It works as long as they don't raise the price too high . If Heinz were, say, double the price of their nearest competitor then people would start to take notice and try the alternatives. Once they got to know some other brands Heinz would have a really hard time winning those customers back.
Actually I disagree.
Heinz ketchup tastes much better than XP CDs. And it's cheaper.
He's almost certainly *not* the originator.
This is not just a Code-Red like virus, it's also a mass mailer (like SirCam). This is going to be bad for the unprotected, and worse for the protected, because we suffer the clawback after effects.
Disclaimer: I was one of the two tech editors for this book.
We decided not to include schemas coverage because the Nutshell books cover not just a description of the technologies, but also best practices. Schemas best practices are only just becoming clear, as can be seen on the xml-dev mailing list. Along with that, Schemas were not yet ratified when the book went to tech review, so we could have only covered an old draft.
Rest assured though, W3C Schemas (and if I can persuade Elliotte, RELAX too) will be covered in the second edition, which I believe is being worked on already.
Try Zvon. http://www.zvon.org. They are a great site that is regularly updated.
:-)
PS: I was a tech editor for XML in a Nutshell, so it's really cool to see it reviewed here
It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.
Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.
These are mantras that I've heard regularly from Lisp and functional language users, but I've yet to see them thoroughly backed up.
Perl coders use functions *all* the time. Even OO method calls are implemented as simple functions. If you need named parameters, use a hash or hashref. There are even modules that validate parameters
so you can have a call signature.
As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list. Now, I don't know if lisp does lazy evaluation, if so that's something Perl doesn't do, and would be a very valid point against it. But you didn't mention that...
Seriously, I'm not trying to flame. I'm geniunely curious about these points.
Matt.
Both have infra red. Just enable infra red reception on your phone (mine is at "Menu/Infra Red") send out your address book from your Palm pilot, and point the two at each other.
:-)
Seriously this works. It uses vCard IIRC so the format is compatible between the two, and it just works. At least it did between my Nokia 8210 and my Palm V.
Oh, you don't have infra red??? Sorry, maybe someone else will answer
There's a lot of validation done on date strings (i.e. check it's 9 digits). For example, there's a lot of code out there that creates filenames based on this 9 digit string, and then there's apps that load up those files. There's also cookies that get set based on the epoch seconds. Any sanity checking that looks for a 9 digit integer is going to go bang. I've come across some of that code where I work. I'm sure other people will too, and it's all too easy to ignore due to the lack of hype surrounding the 1e9s bug.
How are "Word" and "Windows" verbs? ;-)
Welcome to web services.
There's a lot of possible layers there. Yes you can use SOAP and WSDL if you want to, but at it's simplest layer you're providing a service of information (rather than HTML) over the internet (doesn't have to be over HTTP). Slashdot is providing a simple web service in its RSS feed. I think you'll see a lot more people coming to the conclusion that they don't need SOAP and WSDL. Straight XML served over HTTP perhaps with parameters in the querystring is an excellent way to deliver web services.
I have a paper on why this is an excellent way to do things that I gave at the open source conference, but my web server is offline right now and won't be back up for about 4 weeks (due to the wonderfulness of British Telecom). When it's back, you'll be able to find it at http://axkit.org/docs/presentations/tpc2001/
Just in case you still don't believe me, read what Tim Bray, one of the co-authors of XML has to say about it.
You're talking about NAMESPACES!!! Not DTDs.
Don't believe me? Read it from the author of the XML spec. See also my own posts in that thread.
Now slashdot moderators, please read some damned XML books before moderating crap like the above up. I recommend XML in a Nutshell, which I was a tech editor for.
OK:
$ g-request http://slashdot.org/slashdot.rdfx -ns#"
...
<?xml version="1.0" encoding="ISO-8859-1"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-synta
xmlns="http://my.netscape.com/rdf/simple/0.9/">
Sorry, no cigar. This does not contain a DOCTYPE declaration. Try an RSS 0.91 file, e.g. from xmlhack.com:
$ g-request http://xmlhack.com/rsscat.phpd td">
...
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"
"http://my.netscape.com/publish/formats/rss-0.91.
<rss version="0.91">
You can not run a validating parser solely on this. Because the URIs given above are in fact (what you appearently do not want to understand) only Namespace, and not a reference to the DTD.
No, you cannot run a validating parser solely on the first one because it uses XML namespaces! Try the RSS 0.91 file format. That's what we're talking about here.
There is no defined way to automatically determine where to get the DTD. You need to get it yourself and supply it to your validating Parser.
I, and the XML spec, beg to differ. I quote:
[Definition: The SystemLiteral is called the entity's system identifier. It is a URI reference (as defined in [IETF RFC 2396], updated by [IETF RFC 2732]), meant to be dereferenced to obtain input for the XML processor to construct the entity's replacement text.]
How do you dereference HTTP URI's? Well shock horror you use the HTTP protocol! ;-)
I've given the XSL(T)-Example. The XSL(T)-Declaration contains a URI as well.
No, it does NOT. There is no Declaration, only a start element. The reason being that XSLT uses XML namespaces, and namespaces aren't compatible with DTDs (well, they *mostly* aren't compatible - but I'll leave it to a book like XML in a Nutshell to explain the finer details).
But the DTD is not there, only a information by the W3C, that this is the XSL(T)-Namespace. After all you may imagine that the W3C knows what it does.Correct, the W3C does know what it does. The document pointed at by the namespace (which as you correctly, but confusingly point out, doesn't actually need to exist) at the W3C site is in RDDL. Go to XML.com to find out what RDDL is. (actually it might not yet be in RDDL, because the W3C is only slowly moving over to RDDL. But the Schema namespace *does* point to a RDDL document, and this is a sign of things to come).
A valid XSL(T)-Document does not contain any reference about where to get the DTD.
That's because XSLT can't use DTDs, because it uses XML namespaces.
This was specifically intended so, as the Locations of DTD can change, as the example here shows us.
Actually the reason namespaces chose not to have anything at the URI is because they didn't have a namespace compatible schema system in place at the time, and so nobody could agree what to put there. Now the people on the XML-Dev mailing list have agreed on putting RDDL documents there.
So you are still wrong. Having the DTD disappeared from Netscapes site DOES NOT make problems to validating parsers by default. Just obtain the DTD elsewhere and feed it into your parser.
That's possible if you implement a custom URI resolver, but barely anybody does that because it's not the right way to go about fixing the problem (which is to use a catalog system based on the PUBLIC identifier instead).
But this IS NOT A PROBLEM BY CONCEPT. The W3C recognized that it can be virtually impossible to maintain a ever lasting repository for a DTD, and therefore does not urge you to make any links to your DTD. The URI in the Declaration is only Namespace, and you don't even need to put a Webpage there. The W3C itself had not webpages at there URIs at the beginning. Only after having too much people who do not understand (like you) complaing the added this short text. You can use mailto:bla@fasel or gopher:.. or telnet: or anyother unique URI you might imagine. Just make it unique for a given DTD.
You're talking about namespaces again, not DTD's. Please go and buy a good book on XML (such as XML in a Nutshell, which I was one of two tech editors for) that will help clear up your confusion.
We're not talking about namespaces here. We're talking about DTDs, particularly the SYSTEM identifier, which is meant to be fetchable (it even says so in the XML spec).
RSS 0.91 isn't even namespace aware.
Plus, you say "for simply _using_ RSS you won't even need the DTD". That's only *mostly* true, unfortunately. The RSS 0.91 DTD contains all the HTML entity references that are commonly used in RSS 0.91 files, and an XML parser will choke without these being defined somewhere (and that somewhere happens to be the DTD) (well actually a non validating parser can just ignore the entities (providing they are syntactically correct), but then you'd end up with strange looking content).