> Ned Freed wrote: > > By all means do so if you want, but IMO it's a waste of time. It's like > > that > > cautionary line finance folks use: Past performance is not a reliable > > indication of future results. Just because someone group of implementors > > got it > > right (or wrong) in the past doesn't mean the next group won't get it > > wrong (or > > right) this time. What such a query is effectively trying to do is to > > prove a > > negative. Good luck with that. > > > > Again, the bottom line is that the potential for a screwup is there and > > past > > experience tells us that the potential is sometimes, um, exploited, > > sometimes > > not. And that's more than sufficient to warrant discussion of the issue > > in the > > document. > Let me rephrase it then: as far as I know, there is no evidence > whatsoever that using an HTTP based URI as an XML namespace name so far > has caused excessive traffic. I'm well aware of that but IMO it isn't especially relevant. > I would argue that those who argue against their use will have to > provide such evidence. That might be a legitimate argument if there was no past history of this sort of stupidity in other contexts. Sadly, that's not the case, and that renders your argument invalid. An essential component of sound engineering is anticipation of problems in a particular context that haven't happened before, and one of the main ways we do this is by looking at issues that have arisen in similar but not identical contexts. > And yes, having the specification *warning* against automatic retrieval > is always a good idea (see, for instance, > <http://greenbytes.de/tech/webdav/rfc3648.html#rfc.section.11.1>). Then it seems we're in agreement as to what the minimum is that needs to be done, so this will be my final message on this topic. Ned _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf