On Mon, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
I just posted an update to the environment draft; it should be in the
repository soon.
Seems short and sweet.
In addition to adding a note about using "name."
prefixes to group related standard items,
That note is actually the only thing that gave me pause. When I read:
> Extensions designed for interoperable use SHOULD be defined in
> standards track or experimental RFCs. Groups of standardized items
> MAY choose to use a common name prefix of the form "name.".
it took me a few passes to realize that this was not recommending the
literal prefix string "name." (perhaps relating to the "name"
environment item) but recommending grouping related items by some prefix
"xxx." where "xxx" is replaced by some mnemonic for the category by
which they are related. I dunno if that's even worth mentioning, but
there it is, mentioned.
A couple of other musings, again perhaps not worth mentioning, but
while I'm here:
There is a "host" item listed, which is the FQDN of the local host.
It seems to me that one might want to know the host-only part of that
string. One could obtain it in a round-about way by using the "domain"
environment item and the "host" item; but is it worth adding "host-only" ?
I also think that the draft could benefit by providing for some behavior
in the presence of the "variables" extension, e.g. by defining a
namespace such as "env." and stating what value is returned if the item
is undefined in the implementation. I realize that one could obtain the
values by using :matches, wildcarding, and variable assignments;
having namespace support would be more straightforward.
That's all..
mm