Re: hash editing: removing apple bug ref from SHOULD

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.

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


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


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


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

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.


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

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