Hi All,

We are currently revising the ALTO Protocol draft following the
feedback received at IETF77.  There was much helpful feedback,
including a suggestion of an alternative, fully-RESTful, approach to
the protocol.

One of the possible changes to make the protocol truly RESTful would
be to define a single (or few) entry point for discovering resources
available at the ALTO Server (i.e., services and various resources
within those services); the returned document would be an index for
available resources and their corresponding URLs. A previous
incarnation of the protocol draft (pre-WG-document-days, see
http://tools.ietf.org/html/draft-penno-alto-protocol-01#page-19) used
a similar approach, but the argument was made that this made the
protocol more complicated than it really needed to be.  Thus, the
current protocol instead follows a pattern similar to that used in
many public services deployed today, where URLs are explicitly
defined.

There are other aspects of the protocol that might be changed to make
it fully RESTful (see the thread begun by Martin Thomson:
http://www.ietf.org/mail-archive/web/alto/current/msg00632.html for a
more complete discussion), but the above is probably the first one
which the WG should agree on.

While a fully RESTful approach may provide more flexibility for the
ALTO Service, but it is unclear whether this flexibility is needed in
our context.  In other words, we are looking for consensus and
use-cases as opposed to being fully RESTful just from a compliance
perspective.

Thus, we are looking for input from the WG. Taking into
account all previous feedback, it looks like (in our opinion) there is
no consensus to change the current direction.  At the current stage,
we plan to update the draft to explicitly clarify the design choices
that were made and avoid claiming that the service is RESTful (to
avoid abusing the term).

Thanks,
Rich and Reinaldo
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to