Hi Seairth,

Nice work :) Here are some rather picky comments, starting with the
introduction:

> A "notification" is created that contains a URI to a resource, as well
> as some additional metadata about the notification (and possibly the
> resource itself). The notification is then sent to the intended
> recipient URI. The recipient then examines the notification and uses
> the information to retrieve the resource.

Perhaps "contains the URI of a resource" rather than *to* a resource, and
"sent to the intended recipients." rather than a single recipient URI, and
uses the information "to retrieve a representation of the resource", which
is extremely picky but I think necessary for true REST credibility.

You describe an advantage that both the sender of the notification and the
resource itself must be identifiable by a URI, but the introduction quoted
above says nothing about the *sender* being identified, only the resource
itself and the recipients. It then goes on to say that this disallows the
possibility of retrieval of a notification from someone other than the
claimed sender, but again the introduction does not describe notifications
being retrieved, only sent.

The distinction between Identity and Inbox URIs is very clear :)

There appears to be a partial sentence "By assigning Inbox URIs instead of
using each party's Identity URI."

I think using the RNA namespace URI for versioning needs careful thought,
as bumping up the version can break deployed software that expected a
particular namespace, even when the meaning of the elements has not
changed.

Also, areas of the spec that describe returning the same document and
comparing documents with each other need to be clear on what basis they
are compared; for example at the byte, character, or infoset level.

Is there a good reason for wrapping notification and inboxAgreement in an
rna element? Is the content model for the rna element like this:

rna: inboxAgreement | notification+

The from, to, and cc elements should not be empty, they should be allowed
to contain optional text and markup, such as:

<to uri="mailto:mikeday@..."> Michael Day </to>

(Perhaps you have already covered this, as you state that it may contain
additional metadata elements within it that relate to the sender).

I think the subject should be allowed to contain markup, not necessarily
just text. This has value for all the things that text cannot express,
such as ruby, subscripts and superscripts and who knows what. Yes, people
could use this to include an entire message in the subject. But such
people could do equally stupid things in other ways :)

If you say "nonce", please define what it means for those who don't know.

In Example 10: Protected Resource, you describe Bob as being confronted
with a 401 response. However it's quite likely that his software would
submit the authentication tokens with the first request, as it already
knows that they are required. This avoids unnecessary round trips.

(A common misconception of HTTP Authentication people bring up is that it
doubles the number of requests, when in fact it generally only doubles the
first request, and not necessarily even that if you expect that
authentication will be required).

By the way, that's a very restrictive license down the bottom. No right to
create modifications or derivatives? And the authorship attribution in
implementing software is vague and scary. What if your software uses a
library that implements RNA? Is the attribution requirement transitive?
I think a less alarming license might be worth considering.

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince