Re: [web-annotation] avoid constraining HTTP

I'm not sure I'm following how using a sub-set of HTTP equates to non-HTTP
rules. Won't it be the case that servers running clients specifically
fishing for annotation servers will have an easier time communicating with
them whereas other servers will be simply be quite oblivious? I.e., the
annotation server will simply look like another HTTP (or LDP as the case
may be) server. Is that not the case? It isn't like we're making a superset
of HTTP and some new-fangled server protocol.

_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

On Wed, Jul 8, 2015 at 1:07 PM, Erik Wilde via GitHub <sysbot+gh@w3.org>
wrote:

> @iherman, the question is whether you want this to be a web-level
> thing, or something that allows implementations to take shortcuts that
>  are not allowed per HTTP.
> http://tools.ietf.org/html/rfc5023#section-4.4 (and actually all of
> the RFC) is a good blueprint: in the end it mostly documents the media
>  type, and then says that anything that's allowed by HTTP is fair game
>  and must be properly dealt with by clients (and i think this is what
> @fhirsch is asking for). that's how you become a part of the web. if
> you specifically allow implementers to take shortcuts that are not in
> line with the web, then you tightly couple implementations.
> why would you want to assume that there even is such a thing as an
> "annotation server", and clients should be able to find out that they
> are talking to such a thing? why wouldn't publishers set up servers
> that happily serve AtomPub, annotations, LDP, and who knows what else,
>  and all they would have to do is make sure that this is a
> well-behaving HTTP server serving those resources with the appropriate
>  behavior? when you make special rules, you fragment the web, and that
>  would be a sad thing to do.
> developing a client really does not take that much effort. there are
> HTTP libraries in every conceivable language, and you use those parts
> that are meaningful to you, and handle them according to HTTP.
> @tilgovi, without trying to start a philosophical debate here: a
> protocol as i use the term is a set of conventions that allows peers
> to interact to accomplish some goal. the single greatest aspect of the
>  web is that everybody on the web speaks the same protocol, so i never
>  need to care who i am talking to, as long as they are speaking HTTP.
> if a spec constrains HTTP and expects servers to always follow those
> non-HTTP rules, then clients start taking shortcuts, and then those
> clients will break when somebody wants to use a standard HTTP server
> to serve the protocol. you have then effectively partitioned the web,
> and i think you have already discovered that when you tried to come up
>  with a way to "discover" that a server is a special annotation
> server.
> all i can say is: don't do it. it's bad for the web, and bad for what
> you're trying to do.
>
> --
> GitHub Notif of comment by dret
> See
> https://github.com/w3c/web-annotation/issues/51#issuecomment-119680793
>
>