Paul and I have been having a dialog with Lisa Dusseault, our Area
Director, about launching IETF last call for the APP. We had a
little difficulty communicating but eventually came to understand
each other.
Here's the problem she saw, as a veteran of considerable network-
protocol work. Our current draft's introduction (which is really
short) says "The protocol supports the creation of arbitrary Web
resources..." Lisa came back, saying, essentially, "No it doesn't.
You're hardly constraining the server at all. Don't you need to
cover all the rest of the possible HTTP operations and write rules
for all the corner cases?" She had (reasonably) read the word
"arbitrary" as suggesting fine-grained client control over the
server, which is *not* what APP (nor blog-authoring in general) is
about. So, we need to say that.
Lisa and I hashed out some language in the introduction to make it
clear what we're trying to do here. Paul and I both believe this
would add value to the draft. So here's what we'd like the WG to
agree to:
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.
If we do this, I think we can count on the speedy launching of an
IETF last call, which quite likely will turn up other things we've
missed, but has a reasonable probability of getting APP 1.0 delivered
to the world in a sane timeframe. Then we can all go home.
Here's the proposed text for the Introduction:
======================================================
Publishing systems may choose to accept, reject, delay, moderate,
censor, reformat, translate, relocate or recategorize the content
submitted to them. Only some of these choices are immediately
relayed back to the client in responses to client requests; other
choices may only become apparent later, in the feed or published
entries.
Clients cannot expect to publish and edit resources in an entirely
predictable manner. The same series of POST requests to two
different publishing sites can result in a very different series of
HTTP responses, different resulting feeds and even different entry
contents.
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. Generally, any server response or server content
modification not explicitly forbidden by this specification or HTTP
is therefore allowed.