This is getting far off topic, so this will be my final response on this
subthread.
% It sounds like you are going to have trouble bidding on this one, as
% will any system that is based on Internet messaging protocols. RFC1345
% includes, among other things, definitions of US-ASCII and
% ISO-8859-1. It is going to be tough to conform to RFC821 and RFC822
% without using these character sets that are "part of" RFC1345.
Hmmm. Actually, those definitions are NOT derived from RFC-1345,
though they are mentioned in RFC-1345, so I think you are misreading
something.
The specific language used was "part of". Like it or not, these definitions are
"part of" RFC1345. Where they originated is irrelevant. I could make comparable
assertions of the foreign origin of the the entire mnemonic idea, for that
matter. This is therefore the logical conclusion from what was originally
stated. I realize that this probably wasn't the original language, but lacking
any verbatim quotes I can only comment on what was presented.
RFC-1345 defines a particular encoding of many character
sets into a 7-bit representation. It seems clear that said 7-bit
mapping is what is prohibited from implementation.
But this is the entire point I was trying to make. In practice such
requirements are meaningless since any implementation of such a facility has to
be configurable by its very nature. Furthermore, it is only part of a much
larger and far more complex facility for handling all the stuff RFC1345 does
not do. Therefore any vendor who provides such a facility also provides a means
to disable it, thus making it no longer part of their solution.
Vendors run into nonsense like this all the time, since different and
conflicting customer requirements are a fact of life. Sometimes there is a good
reason for it and sometimes not. It doesn't stop vendors from bidding on
contracts and it doesn't stop them from getting them, even when it is clear
that the intent is to exclude their product or their approach from
consideration.
Speaking as a vendor, I've been on both sides of this issue more than once.
I've helped write responses to RFPs that were clearly intended to only be met
by some other product. Sometimes you win on these, but a more common result is
to force the withdrawal of the RFP and its eventual replacement with a new RFP
with requirements so specific only one product can meet them.
I've also been in the position of having the product someone wants which they
are supposed to go through an "open" process to purchase.
I have also encountered situations when selling into northern Europe where
support for RFC1345-based conversions was a condition of sale. This was not in
a formal RFP, but customers rarely have any problem communicating requirements
to vendors even without the formal mechanism an RFP provides.
% This sounds to me like the typical garbage that often ends up in RFPs when
% someone is attempting to exclude some vendor from the process without
% explicitly coming out and saying it in so many words. Unfortunately, such
% language all too often misfires.
While true that contract language attempting to exclude/include
vendors rarely works, I don't think that is the case here. I think it
highly likely that the language in question was designed to preclude
having that user base become dependent on use of a non-standard,
non-general mechanism for character set representation.
I have absolutely no problem with this. But if this is what they were after,
why not just say so? The result will be to exclude products that *depend* on
mnemonic for presentation to users. I don't know of a single product on the
market that has such a dependency, but that's beside the point.
An even better approach is to specify what you want to use that isn't mnemonic,
and mandate support for that or at least for something with comparable
characteristics. And if you don't know what it is that's better, you'd better
stick to generalities about how it is supposed to work or you'll find yourself
the proud owner of software that uses mnemonic encodings that don't happen to
agree with RFC1345.
I am aware of
3 separate cases where similar RFC-1345 language was proposed for
inclusion in an RFP. I'm not sure how many RFPs actually ended up
with the language after the lawyers were done.
Probably all of them. The legal review process doesn't handle such technical
requirements very well.
Ned