Re: Comments on the HTTP/1.0 draft.

Marc VanHeyningen writes:

> Generally, I think the draft of Nov 28 is very good.

Thanks.

> Rather egregiously missing is a reference to transmitting network
> objects in canonical form.  Section 3.2 should mention this; a
> reference to the canonical encoding model in Appendix G of RFC 1521
> (specifically step 2) probably should suffice.  The only place this is
> hinted at is in the tolerance section of the appendices on tolerance
> of broken implementations, but the spec should explicitly say what the
> proper behavior is, just in case any servers every actually do that. :-)

The specified behavior will be "no canonical encoding of the object-body
is required before network transfer via HTTP, though gateways may need
to perform such canonical encoding before forwarding a message via a
different protocol.  However, servers may wish to perform such encoding
(i.e. to compensate for unusual document structures), and
may do so at their discretion."

> As near as I can tell, the spec constrains all header values to be
> US-ASCII, meaning nothing that is not US-ASCII may be contained in
> them.  We might consider permitting non-US-ASCII information in at
> least some headers, probably using RFC 1522's model.

I'd rather not.  If there is a perceived need for non-US-ASCII information
in header field value text and comments (I don't see any), then I think
they should only be encoded by gateways during export.

> In section 7.5, I don't understand the BNF for the CTE header.  CTE's
> don't have subtypes or parameters.

Just trying to improve the world we live in. ;-)
Okay, okay, I'll fix it.

> Regarding busy server errors, a "Retry-After:" field might be
> reasonable, but I would prefer to just make it an HTTP-date rather
> than inventing something new for clients to have to parse.  If we were
> going to use relative dates, there are plenty of other places (like
> Expires:) where they make as much sense.  A pointer to an alternative
> address also seems like a sensible way to handle timeouts.

Actually, I was going to propose adding an optional delta-seconds
for Expires as well, but not until HTTP/1.1.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Wednesday, 30 November 1994 06:05:38 UTC