Re: Need one more draft

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

* Tim Bray <Tim.Bray@xxxxxxx> [2007-01-31 00:05]:
> 1. Do a protocol-13 draft, including the text below in the
> introduction, and
> 2. Fix the bugs and editorial nits reported against protocol-12, and
> 3. Incorporate the latest Snell typeparam draft, which seems to
> have good support.

In favour for the most part.

I don’t really like the text, though.

> Publishing systems may choose to accept, reject, delay,
> moderate, censor, reformat, translate, relocate or recategorize
> the content submitted to them.

Why is this list so long and specific? Is it actually
comprehensive? In that case, should server implementations
actually be bound by it? If not, or if it’s not comprehensive,
wouldn’t it be better to be more conversational here?

> Clients cannot expect to publish and edit resources in an
> entirely predictable manner.

This is superfluous. Clients can never ever expect to publish and
edit resources in an entirely predictable manner, whether in APP
or otherwise. I understand why it’s in there, but there’s gotta
be an actually useful way to say that.

> As a result of this model, client software has to be written
> flexibly to accept whatever the server decides are the results
> of its submissions.

Again, this seems redundant, though I understand why there is a
desire to say something of the sort. I think the key point is
that not only are there many different exceptional and error
conditions, but that even success conditions are wildly
unconstrained.

I think the following copy conveys that point more explicitly
while being shorter and more conversational:

    Publishing systems are under few obligations. They
    are explicitly allowed to ignore or override almost any
    aspect of any request in any way they prefer. Only some
    of these choices must be immediately relayed back to the
    client in the request response; others may only become
    apparent later by examining feeds or published entries.
    Since each publishing system may make different choices,
    clients must be prepared to handle widely varying results
    even when processing responses to successful requests.

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