RE: questions -- clarifications requested

  ]  > And the wording in section 6.2.2 should change to say that the response
  ]  > "should" include a Location header field, instead of "may", when the
  ]  > entity in the response corresponds to a resource.
  ]  >
  ] I don't know -- I think you should look at the uses of "should" in
  ] 8.19 a little more closely.

  I'm not sure what your objection is.

My objection is that there is no reason to require Location headers
unless the server has a reason to include them.  The current spec does
not require them except in a few specific instances (like 302 responses,
which I think is the only required place), and I don't see any reason
it should be changed to make them required.

  But, if a server doesn't include 
  a Location header field in a response to POST, then you're shopping 
  basket application won't work, just as you seemed to be complaining 
  about.  

That's right, but not all applications are the same as my example.
The point is that a server wanting to implement an example like mine
can do so, and one that is doing any of an infinite variety of other
things doesn't have to behave the same way.

  So it seems to me you should be in favor of a stronger wording.

No, I'm in favor of using things where they make sense and not otherwise.

  As to the meaning of should, lots of RFCs use the following definition 
  for "should":

		This word or the adjective "RECOMMENDED" means that there
		may exist valid reasons in particular circumstances to
		ignore this item, but the full implications should be
		understood and the case carefully weighed before choosing 
  to do so.

  Thus, "should" shouldn't be used if one of the exceptions is (e.g.) 
  "when using POST" -- i.e., a very common thing.

  Paul

I think, as you suggested, you may be reading some other document than
the one I'm reading, as all the uses of "should" in the various
descriptions of the Location header I have only refer to what the URI
in the header "should" be like, not when the header itself "should" be
present  (except the discussion on 302 responses, which is uncontroversial)

--Shel

Received on Wednesday, 30 August 1995 20:51:34 UTC