Re: hash editing: removing apple bug ref from SHOULD

On 6 Dec 2012, at 22:59, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:

> 
> On Dec 4, 2012, at 01:56 PM, Henry Story wrote:
> 
>> 
>> 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.
> 
> I said that the tool is widely deployed.
> 
> I have made no assertions about its current usage levels,
> which I do not dispute are far from its deployment.
> 
> You have asserted that it is a little-used tool, and based
> on this current usage level, you seem to believe that it
> will remain so -- even when the technologies we're trying
> to boost here increase uptake, and users therefore have 
> added incentive to use this pre-installed and easy-to-use 
> (albeit apparently buggy) tool.
> 
> 
> 
>>>> 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.
> 
> 
> I'm asserting that my argument against MUST is *also* an
> argument against SHOULD and for the far looser MAY.
> 
> 
>>>> 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.
> 
> The fact that you don't *see* it as making a case against SHOULD
> does not make it a fact that it *doesn't* make such a case -- and
> I assert once more, it *does* make a case against SHOULD.
> 
> 
>>>> 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.
> 
> What's the typo?
> 
> OH!  Are you saying that you meant to say there, that the
> redirect should be from <http://some.eg/foaf%23.*> to
> <http://some.eg/foaf#.*>, where the ".*" is means as regex
> "0-infinite wildcard"?
> 
> 
>>> 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 )
> 
> Again -- 
> 
> If the # is SHOULD, and tools are percent-encoding that 
> character at various points, and other tools are *not* 
> percent-decoding, then the end result will be MANY ERRORS,
> and poor user experience, until and unless implementors
> all decide to break the SHOULD with the justifiable argument
> that IT BREAKS THE EXPERIENCE.
> 
> Thus -- the # should *NOT* be SHOULD, and people who are
> implementing WebID functionality should have the freedom
> to choose hashed or hashless based on their audience/target
> user-base (say, if your target is Mac users, you won't want
> to use hashed, because of the issues I've highlighted ...
> but you'll be trading off some degree of performance ...
> though that performance could be lost even *with* hashed
> URIs if you 303 at some other point for whatever reason...)
> 
> 
>>>> 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. 
> 
> Yes, and gee, thanks.
> 
> 
>> But this particular argument ( the one I removed from the wiki )
>> does not work against SHOULD.
> 
> Yes, I say again, it does.  Just because you don't see it,
> doesn't mean it isn't there.  (Black swan!  Open world!)

This is a question of logic. That is I am taking all possibilities
into account. Your argument still does not work against SHOULD
since 

  1. SHOULD allows you for good reasons to make exceptions, 
     ( and you claim to have a good reason )
  2. you have the  redirect from http://profile.eg/joe%23me to http://profile.eg/joe 
     as an option.

> 
> 
>> 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.
> 
> 
> Indeed.  Then please don't simply paint over the ones with 
> which you disagree.

I am pointing out logical impossibilities in arguments, those
are the ones I am picking out at present. Not arguments with
whose conclusions I disagree - I have not made up my mind what
the conclusion should be. 

> 
> We're working with intelligent people who can evaluate our
> arguments themselves -- and should have the freedom to do so.

I consider myself intelligent, and well versed in logic. And your
argument just does not work.

> 
> Until the morning!



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