Re: Collection convergence?

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

Tim Bray wrote:
> On Mar 14, 2005, at 4:47 PM, Robert Sayre wrote:
>
> > I think we should delete the sections on "locating" (maybe leave 
> > placeholders), delete text on any response code that we assign no 
> > additional semantics to (everything but 201, right?), delete the text 
> > on expected response codes (I have no idea what that means), delete 
> > the text "request/response body constraints" and define new media 
> > types if we need them because those aren't Atom documents, delete the 
> > section on authentication, and move the SOAP stuff to another document 
> > or delete it.
>
>
> Uh, I'm lacking a bit of context.  Are these obvious editorial moves, or 
> do they fall out of the Slice&Dice Pace, or embryonic proposals to be 
> taken up for the next draft... at least a couple of them sound like they 
> need some substantive discussion. -Tim

Fair enough, a bit of both.

* delete locating:
  the current text has never made sense to me, but you have to find
  these URIs somewhere. ACTION: draft must document state transitions.

* delete response codes:
  obvious editorial issue. If you can delete it without changing the
  protocol, why is it there? Well, sometimes things are tricky, so a
  a few well-placed sentences help. But paragraphs and paragraphs from
  2616? No way.

* expected response codes:
  obvious editorial issue. Doesn't mean anything. Non-normative text in
  normative sections makes for arguments, short-lived documents, and
  guru arbiters. No thanks.

* request/response constraints
  Some of these are not Atom documents and never will be. They have to
  change into Atom documents, or change to something else. That's a WG
  issue. However, the current text is unacceptable no matter what.

* authentication
  obvious editorial issue. This section is over-specified and already
  being flaunted. Out it goes. Point to CGI auth? Sure. Someone write
  it.

* SOAP
  My statement sounded like a threat to delete. That's not what I meant.
  I do feel that a separate document would help prevent the interop
  issues that have plagued this. Our most attentive implementers have
  been tripped up by it. I'm not drinking the REST koolaid here--I
  consider PacePubControl a reinvention of SOAP headers. I would be cool
  with a MUST reference to a separate SOAP doc. Minimum: much more
  extensive coverage.

Robert Sayre