Need one more draft

[Tim Bray <Tim.Bray@xxxxxxx>]

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.