Re: hash editing: removing apple bug ref from SHOULD

On 4 Dec 2012, at 18:09, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:

> 
> On Dec 2, 2012, at 05:56 AM, Henry Story wrote:
> 
>> 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 .
>> 
>> ]]
> 
> Again, I voice my disagreement and extreme dissatisfaction with 
> this "removing arguments" practice. 
> 
> A page of pros and cons should include all such that people have 
> raised, as well as the refutations of any positions which are 
> demonstrated to have flawed basis.
> 
> Positions which are deemed irrelevant to the discussion -- by
> group consensus, not by one individual, chair or otherwise -- 
> may be removed to a new section of the page, or even to a side
> page, but should *NOT* be summarily deleted.
> 
> The wiki history page is *not* a viable place for retention of
> such, as nobody is going to go read revision after revision to
> see what has been inserted and deleted along the way.

This is why I brought this up here. Can you defend why the Apple
key chain is a reason against the SHOULD? Then if you want we can 
get some feedback and see where the community stands on this.

> 
> The wiki page was created to lower traffic on the mailing list,
> and move discussion/argument/thread to the wiki page.  But if 
> you're going to simply remove edits made to the wiki page, then
> that commentary must be brought back to the mailing list, and
> the whole point of the wiki page is nullified.
> 
> 
>> Also could the OpenLink folks put their arguments together and not repeat each other? 
> 
> 
> I would say not.  
> 
> We're speaking as individuals here, not corporately.

The wiki is to put ideas together, not people's voices.

This applies to everyone. People who agree with someone else's argument
should put their arguments together, and put their name together at
the end. It is not the amount of characters that makes the quality of
an argument. If you work for the same company there is even more reason
to coordinate.

> 
> Ted
> 
> 
> 
> 
> 
> 
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
> 
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                             //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>         10 Burlington Mall Road, Suite 265, Burlington MA 01803
>     Weblog   -- http://www.openlinksw.com/blogs/
>     LinkedIn -- http://www.linkedin.com/company/openlink-software/
>     Twitter  -- http://twitter.com/OpenLink
>     Google+  -- http://plus.google.com/100570109519069333827/
>     Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/