However, no one has commented on the other question I asked
in my original message. That question was whether the definition
of a feature in RFC 1327 effectively introduces this feature
in Internet mail, i.e. whether Internet mail does already have
an "obsoletes" feature, since it is defined in RFC 1327.
Or does RFC 1327 add features to Internet mail, which are
only to be used in communicating with X.400 gateways, and
which are not intended for "internal" usage in Internet mail?
I am certain that RFC 1327 does not introduce new features into
Internet mail.
The extra headers defined in RFC 1327 are intended only for use
in tunneling X.400 protocol elements. While some of them could
also be used to allow Internet senders to access X.400 services,
there is absolutely no requirement or expectation that Internet
mail agents will implement them.
In some cases it might be a good idea to extend Internet mail
to provide features already present in X.400. If so, the RFC
1327 headers defined for that purpose might provide an appropriate
interface, or they might not. This would require careful
consideration on a case-by-case basis.
Some of the 1327 headers actually encode X.400 transport-layer
information. Such headers should be used only for tunneling
X.400 mail over the Internet; to do otherwise would cause a
layering violation.
In other cases the IETF should at least consider (a) whether
the Internet mail extension should have the same semantics as the
X.400 feature and (b) the likely impact of the newly-defined
Internet mail extension on the Internet installed base.
While of course it would be nice to have greater compatibility
between X.400 and the Internet mail world, compatibility with
the Internet installed base is the primary concern.
Should the outcome of our discussion on the "obsoletes" feature,
if this outcome is agreement of a specification on how such
a feature should work, be added to the next version of RFC 1327,
since RFC 1327 is the Internet standard which introduces
"obsoletes" into Internet mail, or should such a specification
go into a separate standard?
The successor to RFC 1327 should clearly state that it does NOT
define new features for Internet mail.
To do otherwise would require that RFC 1327++ actually describe
how each feature works in the Internet, outline any new requirements
for Internet user agents or mail transports, etc. This is clearly
out-of-scope for the document. It would also require that 1327++
specify precisely which features should or should not be used in
such a manner. It is simpler not to allow them at all, and highly
desirable that any new features should require greater scruitiny
than an X.400 gatewaying working group could provide.
Keith Moore