- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 10 Oct 2012 13:51:53 +0200
- To: "public-xg-webid@w3.org Group WG" <public-xg-webid@w3.org>
- Message-Id: <E4AC16CA-8B64-4E1B-BE7D-C78AD25E9805@bblfish.net>
On 10 Oct 2012, at 13:34, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 10/10/12 5:12 AM, Henry Story wrote: >> But I think the question is here: is a 301 also a signal of a change of WebID, since >> the document has moved permanently, do #uris in the old document also need to be >> moved permanently? >> >> Henry > > Should it matter how routing occurs if the end result is a WebID and public key association that mirrors what's in the X.509 certificate? That would be the simple answer - and that is I suppose the current position. But I am wondering about this, because when you have a 301 redirect the resulting document relative URLs get interpreted according to the redirected to URL. See Tim Berners Lee's point here: http://lists.w3.org/Archives/Public/public-webid/2012Apr/0006.html So what happens then to #uris. After all they are also relative, right? But now the question is the other way around if you do a #uri on a moved document do you have a #uri on the moved document? Do you query the one or the other? I don't think this is well settled. ( But I'd be happy if we had real RFCs to point to if it has been settled ). In any case the issue in this thread was "transfer of WebID ownership". Does a 301 indicate an intent to move the WebID, just as it indicates a permanently moved resource? I don't know. Henry > > -- > > 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 > > > > > Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 10 October 2012 11:52:40 UTC