From: "Michael Day" <mikeday@...>
>
> > You will notice that Phase 2 is pretty much the same in all three cases.
> > The only difference is who passes a capability URI in Phase 1. So...
what
> > do you all think? Does this work? Is it RESTful? Is there a better
way?
>
> Hmm, I may need to re-read this a dozen times first to make sure I
> understand who is posting what to whom. I find it difficult to map the
> examples that you gave to the idea of sending someone an email, which was
> much easier to see in the earlier versions.


In the various cases (depending on which capability URIs are sent to whom):

The user at http://seairth.com/rna would send notifications to
http://rnaserv.net/bob via http://rnaserv.net/bob/44953324.
The user at http://rnaserv.net/bob would send notifications to
http://seairth.com/rna via http://seairth.com/rna/12345.

Here's a re-wording of the solutions that may make it easier to read:

---

Solution To Pattern #1:

Phase 1: I POST http://seairth.com/rna (my identity URI) and
http://seairth.com/rna/12345 (my inbox URI) to http://rnaserv.net/bob (Bob's
identity URI). I get back a response containing my original entries plus
http://rnaserv.net/bob (Bob's idenitity URI) and
http://rnaserv.net/bob/44953324 (Bob's inbox URI). At this point, I
can assert the relationship between his identity URI and his inbox URI are
valid.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna (my identity URI). If it is valid, I return the
document back again. At this point, because I have confirmed the document,
Bob can be sure of my own relationships between my URI and the capability
URIs (both mine and his). If it is not valid (e.g. because I recognize that
I did not issue http://seairth.com/rna/12345 (my inbox URI)), I return an
error (which HTTP response code?), which tells Bob that something was wrong
and that he should probably invalidate his own inbox URI (as well as not use
the one I, or someone impersonating me, sent him in the first place).


Solution To Pattern #2:

Phase 1: I POST http://seairth.com/rna (my identity URI) to
http://rnaserv.net/bob (Bob's identity URI). I get back a response
containing my original entry plus http://rnaserv.net/bob (Bob's identity
URI) and http://rnaserv.net/bob/44953324 (Bob's inbox URI). At this point,
I can assert the relationship between his identity URI and his inbox URI are
valid.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna (my identity URI). If it is valid, I return the
document back again. At this point, because I have confirmed the document,
Bob can be sure of the relationship between my identity URI and the his
inbox URI. If it is not valid (which would be unlikely, unless someone else
tried to impersonate Bob), I return an error (which HTTP response code?),
which tells Bob that something was wrong and that he should probably
invalidate his own inbox URI.


Solution To Pattern #3:

Phase 1: I POST http://seairth.com/rna (my identity URI) and
http://seairth.com/rna/12345 (my inbox URI) to http://rnaserv.net/bob. I get
back a response containing my original entries plus http://rnaserv.net/bob
(Bob's identity URI).

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna (my identity URI). If it is valid, I return the
document back again. At this point, because I have confirmed the document,
Bob can be sure of the relationships between my identity URI and my inbox
URI. If it is not valid (e.g. because I recognize that I did not issue
http://seairth.com/rna/12345 (my inbox URI)), I return an error (which HTTP
response code?), which tells Bob that something was wrong and that he should
not use the inbox URI I, or someone impersonating me, sent him in the first
place.

---

I think the use of "capability URI" was a bit ambiguous (though I would hope
that Tyler could read it easily enough <g>). Does this work better?

---
Seairth Jacobs
seairth@...