Re: [lisp] Meanign of R bit

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: "Joel M. Halpern" <jmh at joelhalpern.com>

    > how can we know that it should never be set with N and L, but not know
    > what it means?

Look at it as a bit which says 'the meaning of some header fields can be
time-shared to another use'. Clearly, in that case, it makes sense to say
'bits which indicate that those fields are being used to contain _other_
values cannot be set'.

I forget which bits are which (and I'm too lazy to look at the spec :-),
so I don't recall if it prohibits other use of only the 32-bit field, or
of the 32-bit _and_ the 24-bit field. To the extent that it's a true
general-purpose 'research' bit, it makes sense to allow it to use both of
those fields (and therefore disallow setting of _any/all_ bits which
indicate use of those fields).

    > It seems both simpler and more versatile to simpler declare the R bit
    > to be reserved. And to remove all the comments about N or L not being
    > set with R.

The problem with that is that if we want to eventually (and interoperably)
morph the R bit into an actual functional bit (e.g. for checking for outdated
mappings), to do that in an _interoperable_ way we need a tiny bit of
specification about how 'vanilla' ETRs will treat it, so we can design an
interoperable deployment strategy.

	Noel