comments on draft-ietf-http-ext-mandatory-00.txt

Here are some comments on draft-ietf-http-ext-mandatory-00.  (My
apologies if these topics have been beaten to death in the mailing list
already.)

Dave Kristol
==========

Substantive:

3. Extension Declarations
       prefix          = 2*DIGIT "-"
	    The "-" is, of course, superfluous.  It simplifies coding
	    marginally.  Is that why it's there?


       Note: In layered implementations, unknown ext-extension parameters
       should be passed to the upper layers as they may have other mechanisms
       of knowing the semantics of the parameters.

	    This is nice shorthand, but I think you owe the reader an
	    explanation of what you mean by "layered implementation".
	    And I, for one, am unsure which layers are "upper".

3.1 Header Field Prefixes
       matching are introduced by this extension instance. This allows an
       extension instance to dynamically reserve a subspace of the header
       space in a protocol message in order to prevent header field name
       clashes.

	    Seems to me you could still have clashes if, through bad
	    fortune, two extensions happened to choose the same numeric
	    prefix.  Is this approach really better than an arbitrary
	    textual prefix?


       "-". The format of the prefix using a combination of digits and the
       dash "-" guarantees that no extension declaration can reserve the
       whole header field name space.

	    I guess I don't follow the logic here.  Or maybe it's that I
	    don't understand how, with a different approach, some
	    extension could have reserved the whole header name space.

8. Publishing an Extension
       to use a mid, cid, or uuid URI. The association between the extension
       		=================

		I don't recognize these.  Got a reference?

       extension identifier is maintained and kept unquestioned throughout
       the lifetime of the extension. Care should be taken not to distribute
	   =========================

		Seems to me there's no way to gauge the lifetime.  The
		originator may have one idea, but there may well be
		software in the field with a lifetime far in excess of
		the intended lifetime of the extension.  In other
		words, unless there's an expiration built into the
		extension, the extension identifier has to be unique
		forever, I think.

Nits:

4. Extension Header Fields
       mandatory and optional, and two types of  extension declaration scope:
       						^-- delete

       Man, Opt, C-Man, and C-Opt (see section 4.1 and 4.2, and appendix 13
       for a table of interactions with origin servers and proxies).
    CHANGE TO
       Man, Opt, C-Man, and C-Opt.  (See section 4.1 and 4.2, and appendix 13
       				 =====
       for a table of interactions with origin servers and proxies.)
       								  ==
4.1 End-to-End Extensions
       between a party representing the proxy and the party on which behalf
       						change: whose <=====
       it can act, but for example, the parties may be within the same trust
       		     ^-- insert: ,

8. Publishing an Extension
       extension identifier is maintained and kept unquestioned throughout
       			    == -> change: be

Received on Tuesday, 24 March 1998 16:38:05 UTC