ietf-822
[Top] [All Lists]

Re: 8-bit transmission in NNTP

1994-09-19 15:03:18
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.

Taken less literally, you must know that any reasonable implementation with
RFC1345 capabilities can be configured not to perform any RFC1345 conversions.
As a matter of fact RFC1345 should NEVER be applied by default. In addition, as
Keld already stated, RFC1345 is rarely if ever implemented as part of user
agents. Therefore in practice this requirement is totally meaningless, since it
ends up that either the set of qualified solutions is the empty set or the set
of qualified solutions is not limited by this requirement in any way.

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.

                                Ned

P.S. I have seen similar language in RFPs about many other technical issues in
mail. Forbidding %-hack or !-path routing is fairly common, for example.

<Prev in Thread] Current Thread [Next in Thread>