Re: Hash Discussion Overview II - the return

On 8 Dec 2012, at 20:27, Henry Story <henry.story@bblfish.net> wrote:

> The WebID is an http URI is a marketing decision to help us make it
> simpler to specifying things. 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.
> 
> We are not saying that *only* http URIs can refer to agents. We are just
> restricting ourselves here to HTTP URIs for works in different specs, such
> as LDP etc, WebID Auth, etc... 
> 
> 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.
> 
> 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."

I also added a section * be tolerant in what you accept 
referring to Nathan's post
http://lists.w3.org/Archives/Public/public-webid/2012Nov/0260.html

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

Social Web Architect
http://bblfish.net/