From: Per Abrahamsen (abraham@dina.kvl.dk)
Date: Tue Jun 05 2001 - 12:21:37 CDT
davidsen@prodigy.com (Bill Davidsen) writes:
> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
> > chl@clw.cs.man.ac.uk (Charles Lindsey) writes:
> >
> > > I think we need more opinions before including a date parameter,
> > > especially after the lukewarm reception from Google.
> >
> > I'm against.
> >
> > 1. It is not existing practice.
>
> True, but it is based on existing technology, X-No-Archive and
> Expires, so we have a fair idea of what's involved.
Does any archives support the expires header?
> > 2. It adds little value.
>
> I don't think that's a technical issue, depending on how strongly you
> want to support copyright, it may add a lot of value for some people.
The only value I can see is giving them a false sense of security.
> > 3. It makes the header much more complex.
>
> Given that we have added features to other headers which would provide
> the procedures for decoding all of this stuff, only in an implementation
> so crude that all the parsing code was replicated in each and every
> header processing can I imagine that it would be "much more" complex. I
> would assume that any slightly reasonable implementation would have some
> table of options and use that to see if the option was present and set
> the value.
The _header_ gets more complex. A hypotetical "reasonable
implementation" might not be, if such an implementation exists.
> Site with low expertise are likely to be running some available
> software which would get upgraded, are they not?
The one I have seen are so bad I doubt they have bought the software,
but I could be wrong. There _is_ a lot of bad software for sale.
Anyway, since the software doesn't seem to conform to any other
standards other than "our feed accepts the articles", I don't think
implementing features because "the standard requires them" is going to
help.
However, in some situations they have implemented support for
X-No-Archive after the regular users have protested strongly. I
suspect the simplicity of the header have helped promote that
decision.
> Of course you can say that some sites won't do it about every change
> we propose...
Yes, therefore we should always strive for simple to implement
features, adding significant value, and based on existing practice.