- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 31 Oct 2012 12:37:48 -0400
- To: "public-rww@w3.org" <public-rww@w3.org>
- Message-ID: <509153DC.9070709@openlinksw.com>
On 10/31/12 12:24 PM, Stéphane Corlosquet wrote: > > > On Wed, Oct 31, 2012 at 10:46 AM, Nathan <nathan@webr3.org > <mailto:nathan@webr3.org>> wrote: > > All, > > I'd propose the following > > Definitions: > > WebID > An HTTP URI with a #fragment which denotes an agent, when > dereferenced a description of the denoted agent is provided in Turtle. > > Authenticated-WebID > A WebID which has been authenticated using WebID-Protocol > > > WebID Protocol Requirements: > > subjectAltName ... MUST be an HTTP URI and SHOULD contain a > #fragment ... > > > Adding a constraint on #fragment here doesn't make sense to me, people > and implementers are free to mint their WebID the way they want, let > them use 303 redirect if they like it. I know people who don't have a > #fragment in their WebID. This should be an implementation detail, not > a requirement. +1 In line with URI opacity principle [1]. Links: 1. http://www.w3.org/DesignIssues/Axioms.html#opaque -- URI opacity principle . > > Steph. > > > WebID profiles ... MUST be in Turtle, and MAY be made available in > other machine readable formats such as ... > > WebID Verification Agents ... MUST support Turtle ... SHOULD > support other machine readable formats. > > Kingsley: I believe this would encourage best practise and push > people towards #frags and turtle for interoperability, but also > allow your and everyone's tooling to be conforming even when > supporting ProxyURIs and the like. > > Fair? > > Best, > > Nathan > > > > > -- > Steph. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 31 October 2012 16:38:11 UTC