Re: i24: Requiring Allow in 405 responses

SHOULD. If the server can determine the valid list of methods it SHOULD
indicate this with Allow. This mechanism is used for enabling HTTP
extensions in the client such as WebDAV, CalDAV etc and a MAY level
requirement is too weak for this purpose as the client should not be
expected to guess that these features is available even if it MAY.

MAY level requirements is for optional features or alternative ways of
doing things, not things which should be done if you can.

SHOULD is for things which you should do, but where things will quite
likely cope even if you don't. I.e. sending the Allow header where not
sending the Allow header which in worst case makes clients capable of
using extensions not enabling these extensions.

tis 2008-02-05 klockan 08:51 -0800 skrev Mark Nottingham:
> Fair enough. Henrik, any thoughts about SHOULD vs MAY? Roy and Mark  
> both expressed a preference for MAY.
> 
> 
> On 05/02/2008, at 7:35 AM, Henrik Nordström wrote:
> 
> > I meant replacing MUST by SHOULD, making the use of Allow in 405
> > responses a SHOULD level requirement.
> >
> > This is a requirement that is in some cases impractical for servers to
> > implement properly. And it's also a case where it's most likely better
> > the sever doesn't say anything at all if it doesn't know than to try  
> > to
> > guess.. If it doesn't know let the client guess if it want.
> >
> > But on the other hand a 405 without Allow is pretty much equivalent  
> > to a
> > 403. So an alternative approach would be to add a note that if the
> > server can not provide a reliable list of allowed methods then 403
> > should be returned instead of 405, reserving 405 to be used only when
> > the server knows within rasonable doubt what methods it accepts on the
> > resource. And this is probably a better way to address the problem.
> >
> > I do not think relaxing the meaning of Allow is a good idea. If  
> > Allow is
> > given then the client SHOULD assume it's the truth. Changing this  
> > would
> > render Allow as such pretty useless.
> >
> > It's the same for Allow headers in response to GET btw. If the server
> > doesn't really know then there SHOULD NOT be an Allow header in the
> > response.
> >
> > Regards
> > Henrik
> >
> >
> >
> > tis 2008-02-05 klockan 06:39 -0800 skrev Mark Nottingham:
> >> Are you saying that s/MUST/SHOULD/ is adequate, or agreeing that
> >> splitting it into two requirements, making the second a SHOULD, is
> >> necessary?
> >>
> >>
> >> On 05/02/2008, at 4:47 AM, Henrik Nordström wrote:
> >>
> >>>
> >>> mån 2008-02-04 klockan 23:08 -0800 skrev Mark Nottingham:
> >>>> My thinking was that it may be necessary to preserve the MUST on  
> >>>> the
> >>>> presence of the header (in case any software had been written to
> >>>> depend upon its presence), but to loosen the implied requirement  
> >>>> that
> >>>> the list of headers be complete.
> >>>
> >>> SHOULD is more than sufficuent for a such requirement level.
> >>>
> >>> Regards
> >>> Henrik
> >>
> >>
> >> --
> >> Mark Nottingham     http://www.mnot.net/
> >>
> >>
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
>