From: Bruce Lilly (blilly@erols.com)
Date: Sun Feb 01 2004 - 06:12:57 CST
Charles Lindsey wrote:
> In <400E7D4E.4030906@erols.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>> That is not that same as "Non-ASCII characters". If the
>>author
>>is evidently confused by the wording of this section, I would say that
>>it needs to
>>be reworded to make it clearer.
>
>
> OK, I have reworded it to say:
>
> "In particular, transmission paths MUST convey all headers (including
> body part headers and headers within message/rfc822 objects) intact,
> even if they contain octets in the range 128 to 255. These
> requirements include the transmissiom paths between posting agents,
> injecting agents, relaying agents, serving agents and reading agents,
> but NOT the paths traversed by Netnews articles that have been
> gatewayed into Email ..."
That's unacceptable because it breaks backward compatibility with IMAP.
We've had extensive discussions about this, and the WG has been directed
that this draft is supposed to remain compatible with RFC 822/2822, i.e.
the message header does not contain octets with decimal value > 127.
>>This raises another point; section 4.4 also states:
>
>
>> If it comes to a relaying agent's attention that it is being asked to
>> pass an article using the Content-Transfer-Encoding "8bit" to a
>> relaying agent that does not support it, it SHOULD report this error
>> to its administrator. It MUST refuse to pass the article and MUST NOT
>> re-encode it with different MIME encodings.
>
>
>>How exactly does a relaying agent determine the characteristics of another
>>relaying agent?
>
>
> If the two relaying agents are communicating via NNTP, then the question
> does not arise since NNTP is 8bit clean. But use of NNTP is not
> obligatory, so there might well exist some other protocol which might well
> provide some capability enquiry mechanism which might be able to report
> the presence/absence of a capability similar to the SMTP 8BITMIME. In such
> a case, that paragraph would apply.
That doesn't answer the question. If no mechanism for determining characteristics
of another relaying agent is provided for in this specification, then it is
ridiculous for this specification to make "MUST" requirements which presuppose
the availability of such a mechanism.
> The whole point is that our standard doe NOT permit downgrading from 8bit
> to Q-P or Base64 so long as the article remanins within the Netnews
> environment (if it is gatewayed into another environment, that might be
> unavoidable, of course).
>
> Would you like me to propose an alternative wording to the effect that
> relayers MUST not re-encode (except at gateways) and add that the correct
> behaviour if it is believed the receiving agent cannot accept 8bit is to
> refuse to relay.
Yes, but you can stop after "(except at gateways)", avoiding the issue of
how an agent is expected to determine (or guess) what capabilities a
receiving agent might or might not have (since there is no provision for
any suitable mechanism for making such a determination or guess).