At 5:39 PM -0700 7/30/96, Paul A Vixie wrote:
and he has tried to explain it to me several times, and I never can figure
wish you were the only one with this difficulty. Unfortunately, I
suspect you belong to a majority...
a) CERT is a (registered) service mark. Has its use, here, been
authorized by the CERT?
No, but since this is not itself a commercial use, we are safe. If someone
I'm not a lawyer and don't play one on the Internet, but your
analysis of the trademark issues differs markedly from my own. Given other
issues, I think it won't matter, though, since I think the right answer is
to pare down the list to avoid synonyms and aliases. That is, there should
be one true choice for any particular mailbox type. In that eventuality,
"security" becomes a more likely choice for mailbox name than does "cert".
c) SUPPORT, HELP, INFO, and SALES are listed in a lower status.
....
since I was really just trying to document current practice. Though as you
point out, I chose a poor title given that goal.
no real quibble with keeping the list short, for the same reason
you have. Documenting current use is dandy. I guess I was reacting more
to its deprecated tone within the document. Part of the reason I'd like to
see the document treated as a full and formal standard is that it carries
more weight in encouraging full and formal conformance (support).
I don't think that more discussion would be a good thing. All the hard work
There are two different aspects to creating a standard. One is the
specification. You've done a fine job of that. The other task is getting
folks' hearts and minds, so there is community awareness and support and,
therefore, community deployment. This is otherwise called "buy in". That
is the reason that I'm encouraging formal standards status and a bit of
public discussion.
The goal should be for the document to give network administrators
explicit and formal direction as to the addresses they are expected to
implement, as opposed to the addresses that they merely might consider.
I'm not sure I get this. Someone who implements everything in this document
The document uses gradations when defining or directing. Done as a
spec in the usual form, it will simply say "if you support function X, you
need to provide mailbox y". It won't talk in terms of popularity or
occasionality of use, or otherwise state things as discretionary, except to
the extent that a given address might make no sense for a given
organization (e.g., "sales" for a high school, although with funding what
it is, perhaps that's changing.) Neither will it provide alternatives with
the same meaning. The whole idea is to make sure that a sender chooses the
right address. Having a choice of alternatives doesn't help this, in the
spec -- Be strict in what we specify and liberal in what you implement.
(With the requisite apologies to Postel.)
If new standard addresses are to be created, they probably need to be in
...
At Xerox they append caret (^) to such things. I'm not ruling that out, but
This gets into the realm of enhancing the Internet standard for
email addresses and, in particular, with the syntax for the mailbox
portion. It think it would be great if we could get away with it but am
not sanguine about the likelihood of it succeeding.
On the other hand, it you mean it merely as a way of reducing the
likelihood of a collision with existing names -- i.e., no formal
modification to the address standard but just choosing unusual characters,
that's an interesting thought. On the other other hand, the idea is to
capture EXISTING special addresses rather than create new conventions, as
you noted next in your response.
Before anything is standardised in this area we need to discover just how
widely used the names are, and/or how willing people will be to implement
well, that's the reason for suggesting the standards process.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr.
dcrocker(_at_)brandenburg(_dot_)com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org,
info(_at_)imc(_dot_)org