From: "Michael Day" <mikeday@...>
>
> 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.

I have cleaned this up a bit...

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

Sorry. This was an artifact from when the <query> element was in there.
Since that's gone, the associate bullet need to go too.

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

Thanks. I tried. :) Even Tyler should be satisfied. <g>

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

Oops. Removed. I also clean up some of the wording in that area...

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

As per the other conversation (Namespaces in RNA), the namespace stuff has
been entirely removed for now (with the exception of the Extension section).
I have to admit that I have never been too fond of namespaces and would be
just as happy as could be if RNA could avoid them to some extent. :)

In its place, I have tentatively added a "version" attribute...

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

Hmm... Yes, it would probably be a good idea. I'll have to work on that
one ("infoset... *blech*").

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

Yes, that is correct. I have reworked that section to make the statement
more obvious. As for the root element:

1) It provides a recognizable "signature"
2) It solves the problem of a container for multiple <notification> elements

> 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).

Yes, almost all of the elements allow optional content. However, they do
not allow mixed content. They must be elements only. So instead, you could
have:

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

On the other hand, if you are just suggesting the ability to put a plaintext
name in for <from>, <to>, and <cc>, I'd be more inclined to add a "name" (or
some such) attribute:

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

> 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 :)

I'm not sure I'll budge on this one. Allowing <subject> to contain markup
feels like opening a pandora's box to me. Further, it can greatly
complicate user interfaces to be able to support <subject>. In all of the
other elements, additional content can be optionally ignored (see
extension), but I think it would be hard to effectively ignore markup inside
<subject> and still keep subject useful...

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

I've taken out "nonce" and replaced it with "unique key". It was an
incorrect usage anyhow (since "nonce" is related to time).

> 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).

That's not entirely true. A client does not know which authentication
scheme it will need to use until the server tells it. As a result, sending
in user:pwd according to the basic authentication scheme will do little good
if the server is expecting to use digest authentication.



Having said all that, I will be uploading the new version shortly. I want
to add some additional text and see if there are still more places that need
cleaning up...

---
Seairth Jacobs
seairth@...