On Aug 7, 2008, at 3:48 AM, Julian Reschke wrote:
Hannes,
thanks for the pointers....
Tschofenig, Hannes (NSN - FI/Espoo) wrote:
...
Reading through the mails again I unfortunately cannot find a
strong recommendations. It seems that reading through RFC 3205 we
got confused.
Initially, the entire discussion started with LoST where we also
solicited review for a URI scheme, see http://www.ietf.org/mail-archive/web/uri-review/current/msg00601.html
I was pointed to RFC 3205 but we later decided not to define a lost
URI scheme. ...
For the record, there was some discussion in the appsarea meeting in
Vancouver about updating BCP56 (RFC3205).
I think if the conclusion from reading it is that you need new URI
schemes and port numbers for anything "beyond webbrowsing", then
that definitively does not represent IETF consensus (as of today) or
the state of the art, or even recent IETF specifications (CalDAV,
AtomPub, whatnot).
Although I agree with a lot of the tradeoff advice being given in this
thread, I'm not sure if HELD is really the same kind of thing as
CalDAV or AtomPub. The latter definitely involve Web servers holding
all kinds of resources that any HTTP client can download with a simple
GET and, thanks to the content types, have a chance of using
application content in a reasonable way. CalDAV and AtomPub both make
use of other parts of HTTP like DELETE and PUT or POST, caching and
auth and cookies. They are really extensions to HTTP to use HTTP for
special applications.
I'm not certain how the designers of HELD view HELD. If it were an
extension of HTTP for helping clients access, use and maybe author Web
resources which happen to be location documents, that philosophical
position certainly implies use of the http scheme and other REST ful
decisions.
However, if the designers view HELD as using HTTP as a request/
response transport to a service that is not otherwise a Web server,
then that implies a different approach. I'm not against using HTTP
for this, but when that road is taken I try to help the protocol from
suffering from interoperability problems due to ignoring all the extra
features of HTTP that the spec writers probably don't initially think
about using or disabling. E.g. see http://tools.ietf.org/html/rfc5055#appendix-B
-- which could still be improved upon to the benefit of interop --
it narrows down what features of HTTP can be used or can be assumed to
be supported.
Lisa
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf