From: "Chuck Hinson" <cmhinson@...>
>
> - After looking at your reply example, it occurs to me that it might be
> desirable to require that the notification (which contain metadata for
> the message) and the message have parallel existances. (Warning -
> possbily half-baked idea ahead) So, when you send a message, both the
> message and the notification are created on the sender's server as
> separater (but related) resources. Authenticity is acheived by doing a
> GET on the notification resource. When you reply, you reference the
> notification resource on the sender's server rather than the message
> itself. Either that, or messages have to have a link to their
> metadata. Actually, this could be like SMTP messages, except that you
> would make the headers and the body two different resources, with the
> headers being used as the notification. (Of course a lot of the SMTP
> headers wouldnt be useful in RNA)


I've been continuing to give this some thought. At this point, I'm still
not sure whether notifications should have URIs. For instance, in HTTP, we
think nothing of pulling a representation of a resource. But what about
pushing a representation of a resource?

Suppose we were to have a notification that looked like (warning! new look.
online doc not yet updated to match.):

<rna xmlns="http://purl.oclc.org/rna/draft">
<notification uri="http://seairth.com/rna/n/234962">
<from uri="http://seairth.com/rna" />
<resource uri="http://www.seairth.com/web/rna" />
<subject>RNA Specification</subject>
</notification>
</rna>

Now, presumably, if the recipient were to do a GET on
http://seairth.com/rna/n/234962, a representation of the notification would
be returned, looking like the notification just sent. The query process
would be able to ask about the notification instead of the resource, but all
this would prove is that the sender did send a notification which can by
found at the given URI. It does prove that the notification was unchanged
(e.g. is the resource in the received notification the same as the resource
in the notification at the URI. The notification could be returned in
response to the query (as it is designed now), but then we would now have
three different ways that a representation of the notification could be
returned. Not to mention that it seems unRESTful to return a representation
of another resource (the notification) as a response to a POST or GET on the
senders URI.


Also, what would be the advantages for the notification to have a URI?
There may be some, but the few I thought I had come up with turned out to
contain faulty arguements.

I don't want to rule this idea out yet, but I am somewhat unsure of where to
go with it...

---
Seairth Jacobs
seairth@...