Re: Judging consensus for publishing Atompub-features on Standards Track

["A. Pagaltzis" <pagaltzis@xxxxxx>]

* Sylvain Hellegouarch <sh@xxxxxxxxxx> [2007-08-17 19:25]:
> I feel this will make the general spread of AtomPub being
> slowed down if you throw away a request because it is not
> supported. Browsers show us, I think, that better not break
> about things that one of the parties can't do so that the users
> general experience is better.

That’s like saying that status codes 4xx and 5xx should not exist
in the HTTP spec. In practice they do and servers return them all
the time. Hopefully not as often as 2xx, but you takes your
chances.

> I'd rather have the extension draft saying that if an extension
> is used by a client when unsupported by the server, the
> behavior is undefined.

What’s the point of the server declaring no support then? It
seems that you think that the server must explicitly say which
features it does not support. I don’t think that’s useful for
anything.

If you intend to provide support for a particular uncommon
feature, then it’s a good idea to alert clients to the fact. If
your implementation is such that you could not possibly do
something useful in reponse to requests using a particular
feature (particularly a common one), then you need to tell
clients up front.

But if you don’t intend to make a promise about a particular
feature, then there’s no point in saying anything about it.

> The extension proposal is to enhance AtomPub, not make it even
> more drastic.

The purpose of the extension is to allow servers to more clearly
communicate what they can handle. If a server cannot handle
particular requests, I don’t see how it can be *harmful* to
adoption or interop to adjust client expectations up front.

But similar reasoning to what you are bringing up is what led me
to the conclusion that a “forbidden” value for the attribute is
not helpful, and that clients SHOULD NOT rather than MUST NOT use
unsupported features.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>