Moving mailserver: URI Scheme to Historic
Retires the vague mailserver: URI scheme by registering it as Historic.
Melnikov, A., "Moving mailserver: URI Scheme to Historic", RFC 6196, DOI 10.17487/RFC6196, March 2011, <https://www.rfc-editor.org/info/rfc6196>.
@misc{rfc6196,
series = {Request for Comments},
number = 6196,
howpublished = {RFC 6196},
publisher = {RFC Editor},
doi = {10.17487/RFC6196},
url = {https://www.rfc-editor.org/info/rfc6196},
author = {A. Melnikov},
title = {{Moving mailserver: URI Scheme to Historic}},
pagetotal = 3,
year = 2011,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6196 Isode Limited
Updates: 1738 March 2011
Category: Standards Track
ISSN: 2070-1721
Moving mailserver: URI Scheme to Historic
Abstract
This document registers the mailserver: URI scheme as historic in the
IANA URI registry.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6196.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction and Overview .......................................2
2. Security Considerations .........................................2
3. IANA Considerations .............................................2
4. References ......................................................3
4.1. Normative References .......................................3
4.2. Informative References .....................................3
1. Introduction and Overview
RFC 1738 [RFC1738] registers the mailserver: URI scheme as
provisional in the IANA URI registry defined by [RFC4395], defining
it as "Access to data available from mail servers" with no further
details provided. The author of this document is not aware of any
other more detailed definition of the mailserver: URI scheme. The
mailserver: URI scheme as currently specified is not interoperable.
There is a small risk that somebody would decide to implement this
scheme by looking at IANA's URI scheme registry, possibly inventing
some undocumented syntax for it. In order to minimize such risk,
this document discourages any future implementations of this URI
scheme and asks IANA to mark it as Historic in the URI scheme
registry.
There were some previous attempts to provide detailed documentation
of the mailserver: URI scheme, but those efforts were not successful.
Implementors interested in providing instructions for generating an
email [RFC5322] message can instead use the mailto: URI scheme
[RFC6068]. Implementors interested in referencing a message or a set
of messages available from a mailstore over IMAP [RFC3501], POP
[RFC1939], or web [RFC2616] can instead use the imap: [RFC5092], pop:
[RFC2384] or http: [RFC2616] URIs, respectively.
2. Security Considerations
In the past, the mailserver: URI scheme was never properly documented
and thus doesn't interoperate. There are no known implementations of
this URI scheme.
3. IANA Considerations
IANA has re-registered the mailserver: URI scheme as Historic in the
URI scheme registry and updated the reference to point to this
document.
4. References
4.1. Normative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
4.2. Informative References
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
November 2007.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, October 2010.
Author's Address
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
AI ELI5
On this page
§1Why the Scheme Is Retired
RFC 1738 registered the mailserver: URI scheme as provisional in the IANA URI registry, describing it only as "Access to data available from mail servers". No further details were provided, and the author knew of no more detailed definition. As specified, the scheme is not interoperable.
There is a small risk that someone would implement it from the registry entry alone and invent undocumented syntax. To minimize that risk, the document discourages future implementations and asks IANA to mark the scheme Historic. Earlier attempts to document it in detail were not successful.
Nobody ever wrote down how this address type works, so anyone using it would be guessing. Retiring it stops people from guessing in different ways.
§2What to Use Instead
For instructions to generate an email message, implementors can use the mailto: URI scheme from RFC 6068. To reference a message or set of messages in a mailstore, they can use the imap: scheme (RFC 5092), the pop: scheme (RFC 2384) or http: URIs (RFC 2616).
If you want to write an email, use the mailto kind of link. If you want to point at stored mail, use the imap, pop or http kinds of link.
§3IANA and Security Considerations
IANA has re-registered the mailserver: URI scheme as Historic in the URI scheme registry and updated the reference to point to this document. This updates RFC 1738.
The security section notes the scheme was never properly documented and so does not interoperate, and that there are no known implementations of it.
The official list now says this address type is retired. There is no known software that uses it, so nothing breaks.