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

At 16:37 3/24/98 -0500, Dave Kristol wrote:
>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

I have never heard this as an excuse for not doing it again ;)

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

The purpose of the "-" is to avoid the potential corner problem of the
header field name space being filled up. Any other non-nummeric character
would do.

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

I think I will just remove the paragraph - it assumes too much of the
implementation to be of any help.

>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 handling of prefixes must be handled by the extension framework in
order to avoid clashes from independent extensions. The prefixes are
generated dynamically and only linked to a particular instance of an
extension, not the extension itself. This is issue DYNAMIC_NS.

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

Without the dash you could have a set of prefixes like this

	0, 1, 2, 3, 4, 5, 6, 7, 8, 9

and you would have reserved the whole prefix 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?

Think so - will add

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

I think there are two points here:

1) do we need to indicate when and if an extension is no longer and if so,
does it have to be part of the extension framework.
2) What is a reasonable estimate of a lifetime.

Wrt 1) the idea is that if an extension is no longer then it would not be
available and return 410 (Gone) if trying to resolve it. On the other hand
the extension may at that time be ubiquitous and doesn't have to be
resolved as everybody knows what it is. I don't think we have to deal with
this here.

For 2) I would suggest that we use Harald's notion of reasonable amount of
time as 50 years.

Do you agree?




Henrik Frystyk Nielsen,
World Wide Web Consortium

Received on Tuesday, 7 April 1998 17:28:51 UTC