RE: Comments (Part 1) on HTTP I-D Rev 05 (ADAMS1)

		-----Original Message-----
		From:	jg@pa.dec.com [mailto:jg@pa.dec.com]
		Sent:	Friday, November 13, 1998 2:38 PM
		To:	Adams, Glenn
		Cc:	http-wg@cuckoo.hpl.hp.com
		Subject:	Re: Comments (Part 1) on HTTP I-D Rev 05
(ADAMS1)


		> From:	Adams, Glenn
		> Sent:	Monday, October 26, 1998 11:13 AM
		> To:	'http-wg@cuckoo.hpl.hp.com'
		> Subject:	Comments (Part 1) on HTTP I-D Rev 05
		> 

		> 4. Section 2.2, pg. 16, definition of "CTL", fails to
consider that
		> ASCII (and ISO646-1993) consider SPACE (040) to be a
control character
		> of the same status as DEL (177).

		Sorry, no, we handle space differently than CTL, and the
BNF reflects this.

What I'm saying here is that you define CTL as:

CTL = <any US-ASCII control character (octets 0-31) and DEL (127)>

while, in fact, "any US-ASCII control character" includes octet 32 by
definition
as well as 0-31 and 127. If you want to exclude SP from this syntactic
category,
I'd suggest adding "exluding SP (32)" to this definition.

		> 
		> 6. Section 3.4, pg. 21, specifies that "the definition
associated with
		> a MIME character set name MUST fully specify the
mapping ...". Should
		> this not be a requirement placed on the registrant of
a MIME character
		> set and not an HTTP implementation? Or, is this
requirement really
		> stating that any HTTP implementation must maintain a
table of registered
		> character sets known to satisfy this requirement and
MUST NOT use any
		> character set not present in this table? Overall, this
seems an onerous
		> requirement for an HTTP implementation.
		> 

		I'm not the MIME expert of the working group, but I take
this to mean 
		that this is just a restriction on which character sets
may be used, and 
		implies there are character sets that do not meet this
requirement by 
		having external profiling information.  Maybe a MIME
expert can confirm 
		this one.

I'm concerned about whether this use of MUST is stipulating a
requirement
for an HTTP implementation or the entity using HTTP. If it is a
requirement on
the implementation, then the implementation would have to maintain
internal
knowledge about which "character sets" satisfy this requirement.

		> 
		> 10. Section 3.7.1, pg. 26, 1st para., states "An
entity-body transferred
		> via HTTP messages MUST be represented in the
appropriate canonical form
		> prior to its transmission except for "text" types
...". Is it actually
		> the
		> case that servers are validating canonical status of
entity bodies? This
		> contradicts the "entity-body as payload" philosophy.

		No, entities are always payload.  The requirement is
that you have to
		play by MIME rules for that data type, but we
acknowledge the UNIX usage
		of newline line terminators means that text document
line terminators
		don't play by MIME rules.  The Web has worked this way
(just ship the
		bits) from day one, and any arguments that it should
play by MIME rules
		for text payload at this date are doomed to failure.

The problem I have here with this is the use of "MUST". Which entity is
responsible for
enforcing "MUST"? If it is true that entities are always payload, then
it would clearly not
be a requirement on the server or client. In this case, the requirement
is on the entity which
is employing an HTTP implementation and not on the implementation
itself, in which case
this should not be specified as a MUST requirement in this context.

		> 12. Section 3.7.2, pg. 27, 2nd para., states "In all
other cases, an
		> HTTP
		> user agent SHOULD follow the same or similar behavior
as a MIME user
		> agent
		> would ...". This "implied" behavior needs to be made
explicit. What is
		> the behavior of a MIME user agent in this context?

		I think you should go read the MIME specs to find out;
HTTP incorporating
		recommendations for what MIME should do here is a great
way for specs
		to end up contradictory.

I'm not suggesting incorporating parts of the MIME specs into this spec;
rather, that
this be more explicit about which parts of the MIME specs are being
referenced.
MIME specifies many behaviors.

		> 
		> 14. Section 3.8, pg. 28, 1st para., states "Product
tokens SHOULD be
		> short
		> and to the point." and "They MUST NOT be used for
advertising or other
		> non-essential information." As an implementer, how can
one interpret
		> these
		> requirements? Either make quantify them or remove
them.

		I think common sense is in order here. Keep'em short.
Your customers will
		thank you (lower latency, fewer bytes).

		We've seen people put the kitchen sink in them.

		Unless others complain, I plan to keep these as is.

The problem I have here is that common sense is a relative. Without
specifying
any limits (e.g, no greater than 1024 characters in length), anyone can
interpret this
as they see fit.

Received on Monday, 16 November 1998 09:52:55 UTC