Dan Connolly said: | It's OK for individual systems to have conventions about | the syntax of HTTP URLs, but it's an abstraction violation | to standardize such conventions across all HTTP servers. Then I said: | I'm not sure I understand Dan Connolly's objection to standardizing | a version extension to URLs, other than that he is objecting to it. Then Dan, wheeling about, retorted: | URLs are supposed to be opaque strings that identify resources. | | Information providers may encode semantic information in them, but | clients must treat them as opaque, except by private agreement. | | [ Later, guns ablazing ] | | I assure you that Tim Berners-Lee and myself will do everything we | can to prevent you from winning. Now that I understand this position, I agree. Since the major point of version-decorated URLs is to avoid requiring client awareness, leaving URLs opaque is logical. I believe what we are discussing, then, is a convention for attaching version information to URLs, rather than a standard. There are many such conventions -- hosts named "www", for example -- that make URLs readable to humans, even if they do nothing for servers and clients. It seems to me that if we do promote version-decorated URLs, we should propose a convention. This was the thrust of the ,;/ discussion. The whole topic of version-decorated URLs is, however, somewhat at odds with Dan's talk of versioning with links. Version-decorated URLs presuppose that the server has external version control over the web content. The use of links, it appears, is an attempt to implement a versioning system _in HTML_. Before I slight this approach, maybe Dan could explain how those links get there: humans type them in? created by web authoring tools? automatically inserted by an external versioning system on document retrieval? Christopher ---- Christopher Seiwald P3 Software http://www.p3.com seiwald@p3.com f-f-f-fast SCM 1-510-865-8720