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

Glenn sent this to the old mailing list address...  He also needs
a new mailer that doesn't make such a hash out of indenting text...

My comments in ! below.
			- Jim



From: "Adams, Glenn" <gadams@spyglass.com>
Date: Fri, 13 Nov 1998 14:31:36 -0600
To: "'jg@pa.dec.com'" <jg@pa.dec.com>
Cc: http-wg@cuckoo.hpl.hp.com
Subject: 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.

! I'm not that familiar with the exact definition of US-ASCII control
! character.  I think things are clear enough by the (octets 0-31) comment
! unless you can give me a good pointer to US-ASCII's formal 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.
!
! Could someone with better character set knowledge than I have please comment???
!

                >
                > 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.

!
! I see what you are saying; it is really a requirement on the content
! provider to play by the rules. It is a requirement on the server.
! On the other hand, I believe we can't
! be wishy-washy here, that if a payload is typed with a MIME type,
! we REALLY want that type's canonical form transmitted rather than some
! random transformation of it.  Otherwise, there is not much use to
! the type information anyway.  I agree it is unlikely that people will
! bother to write too many servers that bother to check, but it is
! quite possible that an authoring tool might do such checks (often,
! by automatically figuring out the type from magic numbers stored in the
! file.  Despite the fact that it is probably unenforcable, I think we
! should stick by our guns and say MUST.
!

                > 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.
!
! No, I have no concrete ideas of how things might be improved here, and
! we've already bowed many times at the MIME altar.  At this date
! we're not going to spend more time worrying about MIME.
!

                >
                > 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.

!
! Look, they are shooting themselves in the foot.  We just wanted some
! way for a user or customer to point to the spec and tell the stupid vendor
! "You aren't playing by the rules; fix it".  Any number you set will just
! encourage people to do dumb things here.  I believe things are fine the
! way they are.
!

Received on Tuesday, 17 November 1998 13:08:58 UTC