Re: WORKING GROUP LAST CALL

------- Forwarded Message

To:  http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Subject:  Re: WORKING GROUP LAST CALL 
Mime-Version:  1.0
Content-Type:  text/plain; charset="us-ascii"
Date:  Thu, 30 May 1996 23:07:56 -0400
Message-Id:  <19558.833512076@worf.mks.com>
From:  "David J. Fiander" <davidf@worf.mks.com>

These aren't, for the most part technical comments on the draft,
but editorial.

section 1.3: Terminology

How about sorting the terms alphabetically, the way other
standards do?  While separating related terms will be a pain,
looking them up will be a lot simpler.

! One uses alphabetical order if there is no better organization
! (if lists are long, the lookup consideration becomes more and
! more imporant.)  The current sort is topological (i.e. terms
! are all defined before they are used), and this is better for
! first reads of the document.  The current list is 2 pages
! long, so I don't think the lookup problem overrides the
! comprehension gains.  I think I'll leave it as is unless
! more people complain.
!


section 1.3: Terminology: definition of proxy

Last sentence: replace "A proxy must" with "A proxy MUST"

! Nothing in this section is normative, so it seems
! inappropriate to state the requirements here.
! You do bring up again the problem noted elsewhere in the list
! that we need somehow to indiate what is required more clearly
! for clients, proxies, caches and servers.  We plan to try to
! do such a table for Draft standard, but I think I'll defer this suggestion
! until then.
!
section 5.1.1 Method

Last paragraph: figure out what's generating the message "Error!
Reference source not found.".
!
! fixed.  Unfortunately, Word isn't as nice as I'd like about dealing
! with invalid cross-references when working with revisions.
!

section 5.1.2: Request-URI

Last paragraph, before terminal "Note":  replace

	Invalid Request-URIs SHOULD be responded to with an
	appropriate status code.

with

	Proxies SHOULD respond to invalid Request-URIs with an
	appropriate status code.

unless, of course, that the original sentence should apply to
both proxies _and_ origin servers.  In that case, the sentence
should be moved up a sentence or two, so it's not buried between
to requirements on proxies, and it should still be reworded to
include an active agent.

! 
! I agree.  I believe this is true for both origin servers and
! caching proxies, so I say server for the generic case.....
!

section 8.2: Entity Transmission Requirements

third paragraph:  move the parenthetical remark "(clients
SHOULD remember ...)", which imposes a conformance requirement on
clients to the end of the bulletted list which begins the
section.  Hiding conformance statements in asides is a Bad Thing.
!
! I reworded to get the requirement out of parenthesis, but
! I don't think it makes as much sense if put up in the bulletted
! list, as it separates the reson for the requirement from the requirement.
!

section 13.2.5: Disambiguating Expiration Values

Delete the second period at the end of the last sentence in the
section.

! fixed

section 13.3.1: Last-modified Dates

Insert a space between "the" and "Last-modified value." at the
end of the sentence.

! fixed.

section 13.3.3: Weak and Strong Validators

This section states that

       	The weak comparison function SHOULD be used for simple
	(non-subrange) GET requests.  The strong comparison
	function MUST be used in all other cases.

However, section 3.11, Entity Tags, states that

	The weak comparison function MAY be used for simple
	(non-subrange) GET or HEAD requests.  The strong
	comparison function MUST be used in all other cases.

Which one is correct?

!
! MAY is correct.  I also added a short note in 13.3.3 to better motivate
! implementation of weak validators, since we lack an implementation
! document at this time.
!
section 13.3.3: Weak and Strong Validators

This section states that "Section 13.3 gives the syntax for
entity tags."  That should be "Section 3.11 gives ...."
!
! actually, it should be a reference to ETag, section 14.20
!

section 13.3.4: Rules for When to Use Entity Tags ...

The first list entry claims that servers "SHOULD send an entity
tag validator unless performance considerations support the use
of weak entity tags".  That should probably be "SHOULD send a
strong entity tag validator".

!
! It is certainly confusing as written.  I've rewritten the requirements
! list to: 
! HTTP/1.1 origin servers:
!	o SHOULD send a entity tag validator unless it is not feasible to 
!		generate one.
!
!	o MAY send a weak entity tag instead of a strong entity tag,
!	  if performance considerations support the use of weak entity tags, or
!	  if it is unfeasible to send a strong entity tag .
!
!	o SHOULD send a Last-Modified value if it is feasible to send
!	  one, unless the risk of a breakdown in semantic transparency that
!	  could result from using this date in an If-Modified-Since header would
!	  lead to serious problems.
!
!  Which encapsulates my understanding of the intended requirements.
!


The phrase "SHOULD NOT" should not be in courier font.

!fixed.
!
! Thanks for the comments...
!			- Jim

Received on Friday, 31 May 1996 10:07:30 UTC