Re: hash editing: removing apple bug ref from SHOULD

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

> 
> On Dec 6, 2012, at 05:19 PM, Henry Story wrote:
> 
>> 
>> 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 )
> 
> SHOULD allows *implementors* to make exceptions for good 
> reasons.
> 
> I am suggesting, strongly, and more strongly by the minute,
> that the spec SHOULD NOT set things up such that implementors
> go down a known-flawed path (i.e., hashed URIs) until they
> run into enough road blocks to each decide that they have
> good reason to NOT conform with the SHOULD advice.

Ah, you are arguing that WebIDs with Hash URIs SHOULD NOT be WebIDs?
Because of a bug in a rarely used tool on OSX?

That would be a different argument from the one I removed. 

> 
>> 2. you have the  redirect from http://profile.eg/joe%23me to http://profile.eg/joe 
>>    as an option.
> 
> Yes, and setting things up such that all deployers/users have
> to handle this painful scenario is *definitely* going to increase
> uptake and usability of WebID technology....
> 
> Or maybe, not.
> 
> 
>>>> 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. 
> 
> If you delete an argument from the wiki page, you've painted 
> over it.
> 
> If it's impossible, point out the impossibility, and be done.

RFC2119 says about 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.
]]

You claim to have a valid reason for your choice, so solution 2 with a SHOULD allows you to use non hash uris if you have valid reasons. Hence your argument is not an argument against position 2:

"A WebID MUST be an HTTP(S) URI and SHOULD be an HTTP(s) hash (#) URI"

Note that this reason is only valid for as long as Apple does not fix their keychain. 
If they do it tomorrow, then your arguments vanish.

> 
> My logic may have flaws -- but I've yet to see you point out
> a fatal one, which an impossibility would be.

You argument is just not an argument against position 2. 
That's why I removed it from the section of arguments against position 2.
> 
> 
>>> 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.
> 
> "...for me," that is, for Henry.
> 
> Kindly allow others to form their own conclusions by not 
> censoring topical arguments on wiki pages.

We can discuss this tomorrow at the teleconf if you want.

> Perhaps the logical consistency of my position ("WebID SHOULD be 
> HTTP URI", period, end of sentence, "MAY be hashed" is left to 
> be inferred [or not] by the reader; I'll tolerate MUST be HTTP 
> for this iteration) has might be confirmed by your consideration 
> of this question --

I don't deny that the 3 position 

"MUST be an HTTP(S) URI" 

is logically consistent. I am just trying to make sure that
arguments in each section are doing some work.

> 
>   Why does the Linked Data meme (Five Star or original form)
>   stop at "HTTP URIs", and not say "hash-based HTTP URIs"?
> 
> Presuming WebID is meant to align with Linked Data (and that is
> definitely one of my presumptions), I have yet to see a strong
> justification for WebID to go further than Linked Data along
> this line...  
> 
> And we're back to "WebID MUST be URI, SHOULD be HTTP(S) URI," 
> full stop.

The removal of your argument section against position 2
does not say anything about the overall state of the argument, or
which one is the best, or which one will be selected.


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