Re: Need one more draft

[James M Snell <jasnell@xxxxxxxxx>]

+1.

- James

Tim Bray wrote:
> 
> 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.
> 
>