Re: remove PATCH, COPY, MOVE, DELETE, etc.? Upgrade?

> I'll disagree with you there.  I think logical completeness is an
> important part of any proposed standard, and I tend to oppose any
> change until the change is complete.

HTTP-WG is in a state of crisis. We urgently need a standards-track
document that

* resolves the ambiguities in HTTP/1.0
* deals effectively with caching
* supports those features that vendors have implemented because of
  customer demand (state tracking, range retrieval)
* reduces security exposure by supporting new authentication

What we don't need are arguments of the form "if we have X, we must
have Y, because Y is necessary to complete X."

We're going to immediately start work on HTTP/1.2 as soon as we finish
1.1. Things that get left out of 1.1 are not doomed to be left out
forever.

Focus.

>> My reason for suggesting that DELETE, TRACE and WRAPPED not be in 1.1
>> is my perception that
>> 1)  there are likely to be disagreements about their form  (pure
>> conjecture)

> I claim that they are innocent until proven flammable.

There *were* disagreements about the form of TRACE, which are
apparently resolved. DELETE is an easy target. (Uh, what's it do to
negotiable resources? Delete all of them? What happens with proxy
caches? ....)  WRAPPED also is controversial, as Rohit points out.
(Uh, how does this relate to SHTTP?)

>> 2)  we've not discussed them (hypermail pointer to
>> discussion/consensus about these in our mail archive?)

> DELETE -> Why discuss it?  There is no controversy about it.

See above.

> TRACE  -> http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0404.html
>   with complete resolution of Max-Forwards proposal in
>         http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0405.html

I accept this as evidence of discussion and review. I'd feel more
comfortable if the review were wider, but I'll mark the status of
'TRACE' as 'probably in 1.1'.

> WRAPPED -> Part of Dave Kristol's original extension proposal, with additions
>   from myself and Rohit (for PEP).  I am not sure whether this qualifies
>   or not.

See Rohit's subsequent message. If the defender of WRAPPED can't
decide which of the two alternatives:

> Bottom line: WRAPPED should stay in, either with the
> application/http restriction and PEP, or without any restriction, so
> long as the client intends application/http. (Damned non-composable
> content-types!)

then how are the rest of us to decide?

> If it's left out, well, you can't build application security solutions within  
> HTTP/1.1.

Why not build them with SHTTP? or SSL?

Received on Friday, 23 February 1996 20:51:05 UTC