<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>An SMTP Extension for email postage</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="An SMTP Extension for email postage">
<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">B. April</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">TrendMicro</td></tr>
<tr><td class="header">Intended status: Experimental</td><td class="header">J. Leslie</td></tr>
<tr><td class="header">Expires: June 16, 2009</td><td class="header">JLC.net</td></tr>
<tr><td class="header"> </td><td class="header">B. Schaefer</td></tr>
<tr><td class="header"> </td><td class="header">iPost</td></tr>
<tr><td class="header"> </td><td class="header">December 13, 2008</td></tr>
</table></td></tr></table>
<h1><br />An SMTP Extension for email postage<br />draft-irtf-asrg-postage-00</h1>
<h3>Status of this Memo</h3>
<p>
By submitting this Internet-Draft,
each author represents that any applicable patent or other IPR claims of which
he or she is aware have been or will be disclosed,
and any of which he or she becomes aware will be disclosed,
in accordance with Section 6 of BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on June 16, 2009.</p>
<h3>Abstract</h3>
<p>The Anti-Spam Research Group is considering research into how
operators of mail systems sometimes might want to pay for transmission
of e-mail. This document details an extension to the SMTP email
protocol for this purpose.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#anchor2">1.1.</a>
Purpose and applicability<br />
<a href="#terminology">1.2.</a>
Terminology<br />
<a href="#SMTP extension">2.</a>
Description of Extension<br />
<a href="#use of extension">3.</a>
Use of the POSTAGE extension<br />
<a href="#anchor3">4.</a>
Operational Considerations<br />
<a href="#anchor4">4.1.</a>
Backwards compatibility considerations<br />
<a href="#anchor5">4.2.</a>
Issuing tokens<br />
<a href="#anchor6">4.3.</a>
Inter-Bank Agreements<br />
<a href="#IANA">5.</a>
IANA Considerations<br />
<a href="#Security">6.</a>
Security Considerations<br />
<a href="#Acknowledgements">7.</a>
Acknowledgements<br />
<a href="#rfc.references1">8.</a>
References<br />
<a href="#rfc.references1">8.1.</a>
Normative references<br />
<a href="#rfc.references2">8.2.</a>
Informative references<br />
<a href="#anchor9">Appendix A.</a>
Change log<br />
<a href="#anchor10">A.1.</a>
Changes from draft-irtf-00 to -00<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Purpose and applicability</h3>
<p>This document defines an extension to the SMTP protocol to
exchange postage charges for transport of email messages, through
tokens issued by a "bank" acceptable to the receiving SMTP server.
</p>
<p>The receiving SMTP server lists currencies and banks it deals with
in the EHLO response; the sending SMTP client chooses one currency and
one bank in each MAIL command. The receiving server lists Postage Due
in each response to a RCPT command; and the sending client includes a
postage token in the DATA command.
</p>
<p>As with snail-mail postage, the postage charged is a transmission
charge: the receiving SMTP server makes no representation about what
may happen at the next step of the delivery chain.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Terminology</h3>
<p>The uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
follow RFC2119.
</p>
<a name="SMTP extension"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Description of Extension</h3>
<p>Name of SMTP extension: Email Postage
</p>
<p>EHLO keyword: POSTAGE
</p>
<p>keyword parameters: list of acceptable currency codes followed by a
list of bank Domain-Names
</p>
<p>An optional parameter using the keyword "BANK" is added to the MAIL
command.
</p>
<p>An optional parameter using the keyword "POSTAGE" is added to the
DATA command.
</p>
<p>Several new SMTP response codes are added. A 254 response to RCPT
and a 455 response to DATA are defined in Section 3.
</p>
<a name="use of extension"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Use of the POSTAGE extension</h3>
<p>A receiving SMTP server that supports the POSTAGE extension will
respond to the EHLO command with the list of supported extensions
including a line with the string POSTAGE followed by a list of
acceptable currencies and a list of domain-names of postage-token-issuing
banks with which it has an established relationship. Inclusion of this
keyword establishes that the receiver supports the Email Postage
extension.
</p>
<p>The EHLO extension-name line shall have the format:
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
"POSTAGE "<currency name>
0*(<comma><currency name>)
<colon>
"BANK="<bank name>
0*(<comma><bank name>)
</pre></div><p>
</p>
<p>The currency name is the particular currency unit. Where the currency
is listed in ISO-4217, that three-letter code SHOULD be used; otherwise
the currency unit MUST be expressed as a domain (usually a top-level
domain, but local domains are permitted), a slash, and the currency
unit name.
</p>
<p>The MAIL command may include the keyword "BANK" followed by the
selected currency code and the domain-name of the bank chosen by the
sending SMTP client from the list of banks offered in the EHLO response.
Inclusion of this keyword establishes that the sender supports the Email
Postage extension.
</p>
<p>The MAIL keyword expression shall have the format:
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
"BANK "<currency name>
<colon>
<bank name>
</pre></div><p>
</p>
<p>A 254 response may be returned to any RCPT command, including the
string "Postage Due:" followed by a floating-point number (not to
exceed six characters, including the decimal point). The number
presented after "Postage Due:" MUST represent the quantity of the
currency code already negotiated (which cannot change during the SMTP
transaction). For example 1.0000 would be one Dollar if USD were
negotiated or one Euro if EUR were negotiated.
</p>
<p>This floating-point number is specific to the MAIL-FROM and the RCPT
(as well as the IP address of the sending SMTP client), and would be
zero in any case where the RCPT recipient had some other arrangement
with the MAIL sender to cover any delivery charge. However, where no
postage is requested, the "Postage Due:" string and parameters MUST NOT
be used in response to the RCPT command.
</p>
<p>When there is more than one RCPT command in an SMTP transaction, the
total postage due will be found by summing the amounts reported for each
RCPT. All postage amounts for a single transaction MUST use the same
currency unit.
</p>
<p> Alternatively, the response to any RCPT command may be a temporary
error "455 You need to negotiate postage directly with that recipient",
indicating that the recipient signals an unwillingness to impose any
particular amount of postage issued by the MTA's bank, but is willing
to negotiate conditions for accepting email (without MTA postage) from
the sending SMTP server. The MTA issuing this error SHOULD be able to
repeat the test of recipient willingness to see if those conditions have
been met due to out-of-band negotiations during the SMTP session.
</p>
<p>The POSTAGE parameter to the DATA command SHOULD be followed by a
token for the total postage due. If the DATA command contains no
POSTAGE parameter, the receiving SMTP server MAY respond to the DATA
command with "550 Cannot deliver without postage."
</p>
<p>The POSTAGE token returned by the bank will be an opaque string
consisting of any ASCII letter or number [a-zA-Z0-9]. The token value
is case-sensitive, so case must be preserved whenever it is copied.
Postage tokens must not exceed 256 characters.
</p>
<p>The receiving SMTP server SHOULD present the token to the chosen bank
before responding to the DATA command. If the token is not valid, the
receiving SMTP server MUST respond with "550 Invalid postage token."
If the token is valid, the receiving SMTP server MUST respond with
"354 Go Ahead" or "550 Insufficient Postage". (The receiving SMTP
server MUST accept the DATA for all or none of the RCPTs.) If the
postage token exceeds the amount of postage due, any mechanism for
credits or refunds is up to the bank, and is outside the scope of
this protocol extension.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Operational Considerations</h3>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
Backwards compatibility considerations</h3>
<p>The sending SMTP client MUST NOT send the "BANK" keyword on the MAIL
command unless the receiving SMTP server has indicated support of this
extension and listed at least one bank.
</p>
<p>The receiving SMTP server SHOULD NOT send the "Postage Due" response
to the RCPT command unless the sending SMTP client has indicated a BANK
on the preceding MAIL command.
</p>
<p>The receiving SMTP server MAY give the "Cannot deliver without
postage" error if it has given a "Postage Due" response during that
transaction. Alternatively, it MAY accept without postage a limited
number of transactions from a sending SMTP client it chooses to
tentatively trust.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
Issuing tokens</h3>
<p>Each POSTAGE domain-name bank MUST maintain a human-readable web
page accessible by "http://<domain-name>" describing to
non-customers how to purchase tokens it issues. This may involve
setting up a new account and/or recommending a consortium of banks
which will facilitate the transfer of payment from an account at
another bank.
</p>
<p>Each POSTAGE bank MUST run a service to issue postage tokens in any
requested amount of an agreed currency name. The tokens will be opaque
strings to all parties except the issuing bank. Payment for tokens
MUST be acceptable in the named currency, and MAY be accepted in other
currencies and/or non-currency units.
</p>
<p>The POSTAGE bank has no responsibility to do any particular
currency-exchange process, except to respond to offers of a different
currency with a floating-point number or a refusal to exchange in that
other currency. Any mechanisms for actual transfer of government
currency are outside the scope of this protocol extension.
</p>
<p>The intent is that any top-level country-code domain MAY be used to
define the available currency choices, but the POSTAGE Domain-Name
need not support all the currency units so defined. Alternatively,
any domain-local "currency", whether or not convertible into some
government-issued money, may be used as a currency-name.
</p>
<p>Whether the token represents actual value already paid or authorizes
deduction of that amount from some existing account is outside the
scope of this protocol. In either case, the first customer to present
the token SHOULD receive the appropriate credit. (Note that the
receiving SMTP server will not know the value of the token and will
need to supply the number and currency units that it presumes the
sending SMTP client has agreed to.)
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3.
Inter-Bank Agreements</h3>
<p>It is not practical to expect any one bank to meet the needs of all
senders and receivers. We expect banks to create agreements whereby one
bank is willing to accept and clear tokens issued by another bank.
The nature and administrative process of any such agreement is not
within the scope of this document. In order to publish such an
agreement, the receiving bank the MUST process the tokens with no
manual steps.
</p>
<p>Senders will encounter requests for postage due where the list of
banks offered does not include a bank that they have an existing
relationship with. To assist in such cases, any bank the sender is
registered with MAY publish a list of banks with which it has an
existing Inter-Bank Agreement. Access to this list MAY be limited to
registered customers. Banks SHOULD make this information accessible by
</p>
<p>"http://<source-bank domain-name>/exchange/<destination-bank domain-name>".
</p>
<p>A reply code of 200 or 204 to such a HTTP query indicates that the
destination bank is willing to accept tokens issued by the source bank;
reply code 404 indicates that the two banks do not have an established
relationship. The source bank MAY provide a newline delimited list of
the currency codes permitted by the inter-bank agreement.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
IANA Considerations</h3>
<p>This document requests that IANA add "POSTAGE" to the list of
registered SMTP Service Extensions:
</p>
<p>http://www.iana.org/assignments/mail-parameters
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
Security Considerations</h3>
<p>This extension intends to allow the transfer of currency value
during SMTP sessions. The SMTP client and server may wish to use TLS
to secure the amounts involved.
</p>
<p>The token passed from client to server has meaning only to the
sending client and the receiving server's bank: neither the receiving
server nor anyone intercepting the SMTP session can know what value (if
any) it carries. Nonetheless, it would be possible in principle for an
interceptor to present it to the receiver's bank before the receiver
does. We assume that the receiver's bank will somehow ensure that its
presentation can only serve to credit the appropriate account.
</p>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Acknowledgements</h3>
<p>
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>8.1. Normative references</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC5321">[RFC5321]</a></td>
<td class="author-text">Klensin, J., “<a href="http://tools.ietf.org/html/rfc5321">Simple Mail Transfer Protocol</a>,” RFC 5321, October 2008 (<a href="ftp://ftp.isi.edu/in-notes/rfc5321.txt">TXT</a>).</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>8.2. Informative references</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="ISO.4217.1981">[ISO.4217.1981]</a></td>
<td class="author-text">International Organization for Standardization, “Codes for the representation of currencies and funds,” ISO Standard 4217, 1981.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
</table>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Change log</h3>
<p>This appendix is intended to be removed by the RFC Editor when this
document is published as an RFC.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A.1"></a><h3>A.1.
Changes from draft-irtf-00 to -00</h3>
<p>
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Ben April</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">TrendMicro</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">22 North Meadow Road</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Amherst, NH 03031</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ben_april@trendmicro.com">ben_april@trendmicro.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Leslie</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">JLC.net</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">10 Souhegan Street</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Milford, NH 03055</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:john@jlc.net">john@jlc.net</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Bart Schaefer</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">iPost</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">60 Galli Drive, Ste T</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Novato, CA 94949</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:schaefer@ipost.com">schaefer@ipost.com</a></td></tr>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright © The IETF Trust (2008).</p>
<p class='copyright'>
This document is subject to the rights,
licenses and restrictions contained in BCP 78,
and except as set forth therein,
the authors retain all their rights.</p>
<p class='copyright'>
This document and the information contained herein are provided
on an “AS IS” basis and THE CONTRIBUTOR,
THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.</p>
<h3>Intellectual Property</h3>
<p class='copyright'>
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.</p>
<p class='copyright'>
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
The IETF invites any interested party to bring to its attention
any copyrights,
patents or patent applications,
or other
proprietary rights that may cover technology that may be required
to implement this standard.
Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
</body></html>