There has been a very interesting discussion on the topic of
an "obsoletes" feature in Internet mail.
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 agree with Keith in saying that RFC1327 does NOT add features to Internet
email. However, I differ with Keith in how significant this actually is in
In practice there is practically no specification of what constitutes correct
behavior for a user agent. X.400 is completely silent in this area -- all it
does is define various service elements and specify whether or not they are
required to be made available for user agent usage. (I don't want to get into
the conditional nature of the various P2 service elements here and how this
differs in the recommendations, the OIW, and other documents.)
The Interent goes a little further, but not much. Sprinkled here and there are
sundry bits of advice as to how agents should work. The advice in RFC822 about
how Sender: should be used is one example. There are similar bits of advice in
RFC1123, and quite a bit more in the BOMBS document series. However, there is
little if any advice on how message-id information is to be managed and used.
There isn't even a clear requirement that message-ids be globally unique (this
despite the fact that it is trivial to make them so), which has led to
implementations which, for example, only switch ids once a day or once a week
(whether they need to or not, one presumes).
It is therefore unclear to me that RFC1327 is in any way incomplete in its
specification of additional services for Internet usage. It defines a bunch of
headers and specifies their semantics, albeit indirectly. This is a
standards-track document so presumably these definitions are unique and nobody
else is supposed to come along and use the same headers in some other,
It is less clear that there's a problem with someone else coming along and
defining, say, a header Foo: with the same semantics as Obsoletes:. But this is
no different than defining, say, a new Message-id: header (which MIME comes
close to doing with Content-id:, for example).
Compare the usage of Obsoletes: with In-Reply-to:. In-Reply-To: is specified in
RFC822 and its semantics are reasonably well defined. Yet support for it is by
no means universal in either message creation or reading agents. And among
those agents that do support it there is considerable divergence on how it is
used on both the sending and receiving sides.
I would therefore say that the specification of Obsoletes is in practice not
materially different from the specification of other end-to-end services
on the Internet.
There may also be substantial problems with tightening up any of this.
Historically most of this stuff is considered to be "a local matter", and
behavior is only specified in cases where the failure to do so has in practice
led to major problems. (I note in passing that the standardization of POP and
IMAP has in fact been challenged on the grounds that mailbox access protocols
are "a local matter" and hence fall outside the realm of IETF standardization
Mind you, I'm not saying its a bad idea. It is a good idea, but it is also
an idea that may be receive significant challenge at some point.
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?
I have absolutely no problem with someone doing an aplicability statement
that says that if you want to use an obsoletion mechanism in mail it should
use so-and-so and such-and-such and that broadly speaking it should work
along the lines of this-and-that. However, I think that to be at all useful
it would have to be part of a broader document which at a minimum deals
with the many issues involving the handling of message and content identifiers.
This probably belongs as part of the BOMBS series of documents the Mail
Extensions Working Group is beginning to look at.