hash editing: removing apple bug ref from SHOULD

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/

Received on Sunday, 2 December 2012 10:57:22 UTC