Re: hash editing: removing apple bug ref from SHOULD

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

> 
> On Dec 4, 2012, at 01:05 PM, Henry Story wrote:
> 
>> 
>> On 4 Dec 2012, at 18:51, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>> 
>>> 
>>> On Dec 4, 2012, at 12:14 PM, Henry Story wrote:
>>>> 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.
>>> 
>>> See --
>>> 
>>> <http://lists.w3.org/Archives/Public/public-webid/2012Dec/0019.html>
>> 
>> [[
>> When a user clicks on a URI with a hash in Keychain.app, they're
>> not going to get where the URI generator intended.
>> 
>> The user is going to have a bad experience thereby.
>> 
>> Mandating, or even strongly encouraging, hash URIs for WebID
>> will increase the odds of this bad experience for Mac users
>> who start to explore how this all works.
>> ]]
>> 
>> yes, understood. But
>> 
>> 1. it is a bug in a little used Apple tool that has very
> 
> "little used" is a baseless opinion.

You are making the statement that it is used to click on something. Please
prove that it is widely used.

> 
>> little impact on anything, 
>>   and this is a standards process, so we don't base our standards on broken tools. What
> 
> Actually, we do.
> 
> "Be liberal in what you accept, and conservative in what you emit."
> 
> This guideline stems from decades of work on internet messaging
> (RFC 821/822 and their successors, among other threads).

Still the SHOULD gives you the wiggle space for this.

> 
>>   if they fix it tomorrow?
>> 2. the SHOULD allows you to do something else if you have valid reasons. I cite RFC2119 on SHOULD
>> [[
>> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
>> ]]
>>  Since you fully understand the implications the SHOULD would allow you to do that.
> 
> I will remind you that I was and am not a blocker on SHOULD, 
> even if I am and remain negative thereon.

ok. I am not sure where I stand, and am looking at the arguments
as they appear on the wiki. It does not help if one puts an argument
against SHOULD that does not argue against SHOULD.

> 
> 
>> 3. There is another workaround: just  redirect 
> 
> *Our* tools will redirect.  We'll build in handlers for whatever
> weirdness the net throws at us.  
> 
> That's part of what OpenLink does, and a big part of why DBpedia 
> worked in the first place (Virtuoso being one of few servers that 
> was built to deal with IE's broken behavior of sending the #frag
> as part of its GET, unquestionably violating HTTP spec).
> 
> But today's effort is about *interoperability*, about making sure 
> that the most tools possible will work with each other.
> 
> I want *other* tools to either handle these issues, or -- far 
> better! -- not have to address them at all.  

yes, I believe the interoperability arguments are already up on the
wiki. So I don't see why adding an argument against SHOULD that does
not make a case against SHOULD is helping.

> 
> 
>>  http://some.eg/foaf%23
>> 
>> to
>> 
>>  http://some.eg/foaf
> 
> Note that such redirections will not typically be from something 
> ending foaf%23 but something ending foaf%23fragID, *and* it won't
> be applicable to *every* GET with %23 in the requested URI...

yes my typo.
>  
> 
> And, even if it were applicable to every GET, it's not nearly 
> trivial to set up on most web servers, or so I've gathered from 
> witnessing many people trying to do so.

I think that is why people are arguing that #uri must be a SHOULD.
( At least that is one of the arguments up on the wiki - it's under MUST,
but I guess it could also be under SHOULD )

> 
> 
>> So your argument is not an argument against SHOULD given the
>> definition of SHOULD.
> 
> My argument *is* against SHOULD, and *for* MAY, given the 
> underlying goal -- maximizing interoperability.


Your general position is against SHOULD and for MAY, and that
is a perfectly reasonable case to argue. 

But this particular argument ( the one I removed from the wiki )
does not work against SHOULD.

You may have already enough arguments against SHOULD for all I know.
Adding arguments that don't argue against what you wish to argue against
is not helping.

In fact I gave you a powerful extra argument for the third MAY solution 
today: 
 - SPDY: with SPDY, my arguments against redirects is a lot less strong.
 - Caching of 303s: if that is correct then it removes a little bit of sting
   ( but I'd like Nathan to point to the Httbis spec )

I would like to see arguments that help us make progress.


  All the best,

	Henry



> 
> 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/