In <3E22B951(_dot_)70503(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
In <3E2019AA(_dot_)30805(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
That is
clearly the intent of RFC 2047. The design flaw, as has been already
mentioned, is decoding encoded-words for transmission.
But nobody is proposing to do that.
The Usefor draft permits it by allowing raw untagged 8-bit data to be
transmitted between generating user agents and gateways.
If some raw untagged 8-bit data is produced then, by definition, it is not
in the form of an encoded-word,
I.e. it is in decoded form. Header fields must use 2047/2231 for non-ASCII
characters; any raw untagged 8-bit data is therefore referred to as "decoded"
for purposes of this discussion.
So you want to apply the word "decoded" to something that was never
encoded in the first place? OK, I'll play.
so the question of "decoding it for
transmission" cannot possibly arise.
Yes it can; if a user agent transmits raw untagged 8-bit data (rather than
the standard 2047/2231 encoded-words).
But now you are saying that something transmitted in "decoded" form must
necessarily have been through a "decoding" process beforehand. Sorry, you
can't have it both ways.
You claimed (and your words are still quoted above, preceded by ">>>>>")
that there was a design flaw in Usefor which involved "decoding
encoded-words for transmission". Will you please explain exactly where in
Usefor it is specified that any encoded-word is required (or even allowed)
to be "decoded for transmission".
You will not be able, because it simply is not there.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5