- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 30 May 2000 13:37:02 -0400
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
The behavior of dereferencing our namespaces will now change. This isn't critical, but for those interested ... Below is a message I sent to someone who encountered a problem with the earlier behavior. Forwarded Text ---- You've unfortunately encountered a problem that results from an attempted hack on browser bugs. The behavior you encountered results from a symlink that links the namespace to an actual specification. The fragment identifiers even work; when you dereference: http://www.w3.org/2000/02/xmldsig#Object you actually see: http://www.w3.org/TR/2000/WD-xmldsig-core-20000510/#Object but the URI in the browser is still show as: http://www.w3.org/2000/02/xmldsig#Object If you then browse the rest of the specification, and click on http://www.w3.org/2000/02/xmldsig/signature-example-rsa.xml that file doesn't exist as you rightfully point out, and it shouldn't really. It isn't my intent to provide another URL for the specification, but good content for a dereferenceable namespace. The symlink is the hack that has some bad side affects; the true problem arises when one tries the alternative below that should work, but doesn't because of browser bugs. It'd be nice to have the server do a redirect. So when you enter http://www.w3.org/2000/02/xmldsig#Object you actually see (both in content and a rewritten URL in the address bar) http://www.w3.org/TR/2000/WD-xmldsig-core-20000510/#Object However, most browsers behave inconsistently with respect to fragment identifiers in redirects. My version of NS drops it all together; IE drops the fragment from the address bar but goes to the appropriate section of the document. Bert Bos document these problems in: http://www.ics.uci.edu/pub/ietf/http/draft-bos-http-redirect-00.txt I originally decided to err on the side of the symlink 'hack' that is inelegant, hard to maintain (mucking with the file system to obtain http service effects), and has the problem you encountered. I've now moved to the HTTP redirect approach, which does the right thing, clearly demonstrates the bug, but results in the user not being taken to the relevant portion of the document in some cases. At 09:18 AM 5/30/00 -0400, Hugo Haas wrote: > >The following information has been sent >from http://cgi.w3.org/cgi-bin/FAQNotice.pl available from the FAQ >webreq, please investigate > > >---------------------------------------------------------------- >Originating URL: http://www.w3.org/2000/02/xmldsig#sec-Schema >Comments: This is meant to be a stable, well-known URL that lives forever and is explicitly referred to by the xmldsig spec (and, probably, by every XML digital signature that uses a DTD), so it would probably be good if it existed, and maybe even had exactly the right contents. I think what's going on is that /2000/02/xmldsig gets mapped to the current version of the xmldsig spec, i.e. /TR/2000/WD-xmldsig-core-20000510 at present. My guess is that the mapping should actually include a whole group of URLs in the subtree under /2000/02/, but it looks as if right now only that single URL /2000/02/xmldsig is getting mapped. End Forwarded Text ---- _________________________________________________________ Joseph Reagle Jr. W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Tuesday, 30 May 2000 13:38:04 UTC