Re: Hash Discussion Overview II - the return

On Dec 8, 2012, at 02:27 PM, Henry Story wrote:

> The WebID is an http URI is a marketing decision

As a marketing decision, it belongs *NEITHER* in the primary 
definition of "WebID" *NOR* in the restrictions of any spec.

Guidance, How-To, even Best Practice?  Fine.  Those are more
marketing in focus.

But the *architectural* documents we are currently contemplating
are not the place for *marketing*!


> to help us make it simpler to specifying things.

Now you're saying it's not about marketing, but about making
the spec author's job easier.

Difficult things always expose that difficulty *somewhere*.

The question is where (and this list is certainly incomplete) --

1. Spec author
2. Implementor/Server Programmer
3. Deployer/Client Programmer
3. End User

I submit that it is best for WebID, that the challenges be 
felt by we who are best equipped to handle and address them.


> Other specs make these types of decisions. There is nothing stopping future specs being more relaxed, just as the meaning of HTML is constantly evolving.

And it is very easy and quick to put out such a future, more
relaxed spec, isn't it?  Just as easy and quick as it is to
put out this first, less relaxed spec....


> We are not saying that *only* http URIs can refer to agents.

... except within WebID, because "a WebID is [*only*] an HTTP(s) 
URI which denotes an Agent."


> We are just restricting ourselves here to HTTP URIs for works in different specs, such as LDP etc, WebID Auth, etc... 

Saying "For simplicity in authorship, this document will only 
address HTTP URIs, but any scheme could theoretically be used"
would be in line with your above.

But that is not what has been said or done to date.


> The Identity Interoperability work <http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability> shows that you can work with a lot of other identifiers, but it is a lot more work then to specify things, and it means that people looking to implement a WebID have a much steeper curve to get in.

Specification may be harder, but people trying to implement don't
necessarily have a steeper hill to climb.

Ted


> Apart from that is there a short argument you would like me to add to this, for your position, in section 3, that does not cover it? 
> 
> I added the following for you:
> 
> "It is better not to have restriction here since there are technical solutions to get to the profile document for both hash URIs and non hash URIs."
> 
> Henry
> 
> On 8 Dec 2012, at 20:03, Toby Inkster <tai@g5n.co.uk> wrote:
> 
>> On Sat, 8 Dec 2012 17:35:35 +0100
>> Henry Story <henry.story@bblfish.net> wrote:
>> 
>>> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash2
>> 
>> FWIW, I don't think WebID should place any restrictions on users'
>> choice of URI; just as it shouldn't place any restrictions on what
>> ciphers are used for the TLS sessions established.
>> 
>> I'm not saying that restrictions should not exist. People shouldn't be
>> using, say, a Caesar cipher (look it up if you don't know) for TLS; but
>> restrictions on TLS ciphers should happen in the TLS specs, not in
>> WebID.
>> 
>> The WebID spec is the wrong *layer* to address this sort of issue. It's
>> an issue that needs resolving (even if that resolution might be that
>> the status quo is OK) at the linked open data level; or maybe even at
>> URI.
>> 
>> So WebID shouldn't place restrictions on what URIs people choose to
>> identify themselves with. I don't even think we should require
>> HTTP/HTTPS; if people choose to use an FTP URI, chances are that most
>> existing implementations of WebID would cope. If they choose to use
>> an NNTP URI... well, I tend to be in favour of giving people enough rope
>> to fashion themselves the very best noose possible.
>> 
>> Be liberal in what you accept; be conservative in what you omit. The
>> spec should accept whatever URIs people want to use; how-to guides
>> should steer people towards sane options.
>> 
>> -- 
>> Toby A Inkster
>> <mailto:mail@tobyinkster.co.uk>
>> <http://tobyinkster.co.uk>
> 
> Social Web Architect
> http://bblfish.net/
> 

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