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

From: Dave Kristol (dmk@bell-labs.com)
Date: Wed, Apr 08 1998 

Message-ID: <352B8615.6088@bell-labs.com>
Date: Wed, 08 Apr 1998 10:13:41 -0400
From: Dave Kristol <dmk@bell-labs.com>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
CC: ietf-http-ext@w3.org
Subject: Re: comments on draft-ietf-http-ext-mandatory-00.txt

Henrik Frystyk Nielsen wrote:
> 
> At 16:37 3/24/98 -0500, Dave Kristol wrote:
> [...]

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

I don't think you understood my point, and I confess I don't understand
yours.

What I'm saying is this:  the syntactic definition could just as well be
prefix=2*DIGIT, with the understanding that a '-' gets used between
<prefix> and the header.  So I could have
	M-PUT /a-resource HTTP/1.1
	Man: "stuff"; ns=43
	43-copyright: more-stuff
	...

> [...]

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

Given what I said above, I don't think it's the '-' that prevents
reserving the whole extension space.  Rather it's the 2*DIGIT part.  You
would have to reserve 00, 01, 02, ..., 99 to hog the space.  (Maybe I
should have listed this point under "nits". :-)

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

I don't think 410 (Gone) is an appropriate status code in this context. 
510 (Not extended) seems more appropriate.

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

I think there are two sub-problems, for a given pair of client/server
hosts.
a) How long should a program that knows it previously used an extension
assume it can continue to use the extension?
b) How long should a program that knows it could *not* previously use an
extension wait before it tries to use the extension again?

Maybe 50 years is the right answer for (a) (though I doubt it), but 50
years is almost certainly the wrong answer for (b).

Dave Kristol