- From: Henry Story <henry.story@bblfish.net>
- Date: Sun, 2 Dec 2012 11:56:49 +0100
- To: WebID Group <public-webid@w3.org>
- Message-Id: <EB245C33-2BA7-4A4F-A9A3-32D060A0766A@bblfish.net>
I removed the following arguments from SHOULD since clearly they don't argue agains SHOULD since it would allow it. [[ Ted Thibodeau * The '''Keychain Access.app''' in Mac OS X takes any SAN that includes a #, and visually presents it correctly. But when you click on that URI (the textual string of which you cannot select and copy), your browser loads the URI with %23 in place of the # -- e.g., Keychain Access.app displays '''http://twitter.com/TallTed#this''' locally, but when I click it, my browser (observed with both Firefox and Safari; no reason to think any other would behave differently) tries to load '''http://twitter.com/TallTed%23this''' -- which correctly 404s. Now, this is clearly a bug in Mac OS X and/or Keychain Access.app -- but this is a very widely deployed tool which demonstrates the folly of forcing a particular URI pattern for WebID. (This is an argument against both MUST and SHOULD for hash-URI.) Kingsley Idehen * Apropos the comments above from Ted, all you have to do is think about platform interop to see that SHOULD is still vulnerable to %23 transformation of # (fragment id) demonstrated by [https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase.png Mac OS X Keychain] which leads to [https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase-2.png THIS] empty page . ]] Also could the OpenLink folks put their arguments together and not repeat each other? Henry Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Sunday, 2 December 2012 10:57:22 UTC