On Sep 19, 14:51, Ned Freed wrote:
} Subject: Re: 8-bit transmission in NNTP
Just as a data point: We recently got from a very large firm, which
shall remain nameless, an RFP for their corporate-wide mail system.
That RFP stated as one of the requirements of the system that it MUST
*NOT* use any part of RFC1345. No explanation for this was given.
% 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. 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.
% 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 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.
}-- End of excerpt from Ned Freed
Ran
atkinson(_at_)itd(_dot_)nrl(_dot_)navy(_dot_)mil