Re: hash editing: removing apple bug ref from SHOULD

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!)


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

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

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