Charles Lindsey wrote:
In <3E255ED5(_dot_)9010206(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
3. And what about the newly-proposed Mail-Copies-To field? Or Complaints-To?
Existing gateways have no syntax information for those, so could not
encode. Not to mention any header fields that might be added in future.
Existing gateways do not encode at all.
Precisely; requiring them to do so breaks compatibility with the
installed base of RFC 1036-compliant gateways.
Headers that might be added in the future are indeed a problem.
There's only a minor problem (remember, we're talking about human-readable
text strings, not protocol elements) in the real world -- that minor
problem is only significant where cut-and-paste or similar operations
are involved. In the ivory-tower Usefor draft world, where encoding
is expected to magically take place divorced from charset and language
information necessary to the encoding process, it's an insurmountable
problem.
> They are
already a problem with email headers and RFC 2047 (and new email headers
are appearing at a faster rate than is ever likely to be the case with
Netnews).
Be careful; that's an area that I've been tracking closely. In the
recent past (four years), in reverse chronological order:
Received-Content-MIC RFC 3335 September 2002
Accept-Language RFC 3282 May 2002
List-ID RFC 2919 March 2001
Content-Features RFC 2912 September 2000
Media-Accept-Features RFC 2530 March 1999
RFC 2047 encoding isn't applicable to Content-Features. All of them
are primarily of interest for automated processing of protocol elements
rather than for human display.
The Usefor draft proposes to establish six new header fields not defined
in any other RFC. The last time an RFC introduced that many at one time
was RFC 2369 in July 1998; of those, three are described as "core header
fields" and the remainder "are not as widely applicable", and all are also
primarily of interest for automated processing rather than human display.