On 07/28/11 08:09, Thomson, Martin wrote:
That said... The way the text is structured implies something more complicated
than it needs to be. That is, it implies that an entry MAY identify a resource
in a way that is not sufficiently defined to actuate that resource. That's
bad. It does the clients a disservice and ought not happen in anything other
than an error condition.
Structuring the description in a different way could alleviate the problem.
1. a directory identifies resources as completely as possible
2. error handling requires good client feedback:
(a) all resources provide responses to OPTIONS requests that identify their
own capabilities
(b) resources provide appropriate HTTP responses so that clients can correct
mistakes (405, 406, etc...)
I think a flow diagram or description of how exactly the client/server
interaction w.r.t. these three ways of discovering resources would be
very useful.
The protocol, as well as discovery, assume the client's first request
would be for the IRD. I do not exactly see why the IRD cannot be
strictly authoritative for non-IRD resources. If it has
non-authoritative knowledge, it should point to IRD of the authoritative
entity -- simple and extensible.
Bye,
Robert
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
