< draft-newman-email-subaddr-00.txt   draft-newman-email-subaddr-01.txt >
Network Working Group C. Newman Network Working Group D. Cridland
Internet Draft: Internet Email Subaddressing Innosoft Internet-Draft Isode Limited
Document: draft-newman-email-subaddr-00.txt July 1997 Intended status: Informational November 16, 2007
Expires in six months Expires: May 19, 2008
Internet Email Subaddressing Internet Email Subaddressing
draft-newman-email-subaddr-01
Status of this memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working By submitting this Internet-Draft, each author represents that any
documents of the Internet Engineering Task Force (IETF), its areas, applicable patent or other IPR claims of which he or she is aware
and its working groups. Note that other groups may also distribute have been or will be disclosed, and any of which he or she becomes
working documents as Internet-Drafts. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering
months and may be updated, replaced, or obsoleted by other Task Force (IETF), its areas, and its working groups. Note that
documents at any time. It is inappropriate to use Internet-Drafts other groups may also distribute working documents as Internet-
as reference material or to cite them other than as "work in Drafts.
progress."
To view the entire list of current Internet-Drafts, please check Internet-Drafts are draft documents valid for a maximum of six months
the "1id-abstracts.txt" listing contained in the Internet-Drafts and may be updated, replaced, or obsoleted by other documents at any
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net time. It is inappropriate to use Internet-Drafts as reference
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East material or to cite them other than as "work in progress."
Coast), or ftp.isi.edu (US West Coast).
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
It is often useful for a single user to have multiple email It is often useful for a single user to have multiple email addresses
addresses which can be used to assist categorizing incoming email. which can be used to assist categorizing incoming email. One way of
One way of doing this is to divide the local-part of an email doing this is to divide the local-part of an email address into user
address into a primary address and a subaddress. The primary and detail parts. The user part is used to route the message within
address is used to route the message within the specified domain the specified domain and the detail part is used to route the message
and the subaddress is used to route the message according to a according to a particular user's wishes.
particular user's wishes.
This specification formalizes the de-facto standard for This specification formalizes the de-facto standard for subaddressing
subaddressing in use today and includes advice and requirements for in use today and includes advice and requirements for final delivery
final delivery agents, MUAs and mail list servers which wish to agents, MUAs and mail list servers which wish to support
support subaddressing. subaddressing.
1. Conventions Used in this Document Table of Contents
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
in this document are to be interpreted as defined in "Key words for 1.1. Conventions used in this document . . . . . . . . . . . . 3
use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Subaddressing Syntax . . . . . . . . . . . . . . . . . . . . . 4
4. Subaddress Support Requirements . . . . . . . . . . . . . . . 7
4.1. Final Delivery Agent Requirements . . . . . . . . . . . . 7
4.2. Gateway/Firewall Requirements . . . . . . . . . . . . . . 7
4.3. MUA Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.4. Mailing List Server Requirements . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Subaddressing Scenarios . . . . . . . . . . . . . . . 9
A.1. Subscribe to Mailing List by Detailed Address . . . . . . 9
A.2. User Controlled Distribution Lists . . . . . . . . . . . . 9
A.3. Mailto URL Indicator . . . . . . . . . . . . . . . . . . . 10
A.4. Support for Special Addresses . . . . . . . . . . . . . . 10
A.5. Priority Categorization . . . . . . . . . . . . . . . . . 10
A.6. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Open Issues and Discussion . . . . . . . . . . . . . 10
B.1. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
The formal grammar in this document uses Augmented BNF [ABNF]. 1. Introduction
2. Definitions Subaddressing is a common technique for providing users with multiple
addresses which can be used for filtering incoming email. A key
feature is that no administrative action is required to provision or
enable a particular detail part; instead, as long as the domain's
mail system is subaddress-aware, the user may use arbitrary detail
parts.
Final Delivery Agent Although commonly deployed, subaddressing has had minimal formal
The final delivery agent is the agent started by the Final MTA documentation; this document attempts to define subaddressing, and
which interprets the local-part of the email address. also define what it means to be subaddress-aware.
Final MTA In general, deployed forms of subaddressing divide the local-part of
The final MTA is the MTA designated by the domain to the left an email address into two strings, seperated by a delimiter
of the "@" in an email address. character. This is most commonly a plus sign, "+".
Local-Part This document does not document all forms of subaddressing, merely
The local-part of an email address is everything to the left the most common form, also known as "plus-addressing". Other forms
of the "@" in the address used for delivery and is formally are also deployed, sometimes using a minus sign, and in some rare
defined in [IMAIL]. It is also know as the "left hand side" cases using encoding rules rather than simple catenation.
of an address.
Mail List Server 1.1. Conventions used in this document
A Mail List Server takes messages directed to it, rewrites the
envelope addresses and redistributes the message to one or
more subscribers.
MTA A Mail Transport Agent (MTA) receives email from other MTAs or The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
MUAs and routes it towards the final MTA. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
MUA A Mail User Agent (MUA) is used by a user to send and read The formal grammar in this document uses Augmented BNF [ABNF].
email.
Subaddress 2. Definitions
A subaddress is information in addition to the address of a
primary mailbox which may be used for categorization by the
recipient.
3. Subaddress Syntax Final Delivery Agent
The final delivery agent is the agent started by the Final MTA
which interprets the local-part of the email address.
A final delivery agent may divide the local-part into two pieces Final MTA
separated by a "+". The primary address is to the left of the "+" The final MTA is the MTA designated by the domain to the left of
and the subaddress is to the right of the "+". A message with a the "@" in an email address.
valid primary address is delivered to that primary address by
default, regardless of the contents of the subaddress. The
subaddress may be used by final delivery filtering (e.g. to deliver
messages with a particular subaddress into a special folder) or by
an MUA.
For example, an address <delenn+grey-council@babylon5.org> could be Local-Part
used to send email to <delenn@babylon5.org> relating to grey- The local-part of an email address is everything to the left of
council business. Delenn can then direct her final delivery agent the "@" in the address used for delivery and is formally defined
to file messages with a "grey-council" subaddress into her "grey- in [IMAIL]. It is also know as the "left hand side" of an
council" folder. address.
When generating a subaddress, the local part of the address MUST be Mail List Server
canonically quoted. A local part is canonically quoted if it is A Mail List Server takes messages directed to it, rewrites the
legal according to both the formal grammer in [IMAIL] and the envelope addresses and redistributes the message to one or more
formal grammar in [SMTP]. The following formal grammar restricts subscribers.
<local-part> in this fashion and distinguishes the primary address
from the subaddress. Subaddress aware MUAs MUST NOT generate
addresses which violate this syntax and subaddress aware final
delivery agents MAY refuse to apply subaddress interpretation to
addresses which violate this syntax.
local-part = local-quoted / local-unquoted MTA
A Mail Transport Agent (MTA) receives email from other MTAs or
MUAs and routes it towards the final MTA.
local-quoted = <"> primary-q ["+" subaddress-q] <"> MUA
A Mail User Agent (MUA) is used by a user to send and read email.
local-unquoted = [primary-c] ["+" [subaddress-c]] Detail Part
A detail part is information in addition to the address of a
primary mailbox which may be used for categorization by the
recipient. It is also known as a subaddress.
primary = *(SAFEQ-CHAR / QUOTE-CHAR) User Part
;; This is the syntax for an unquoted primary A user part is that portion of the local part which indicates the
;; address. If it fits canonical form (primary-c) primary mailbox. In a mail system which is not subaddress-aware,
;; it is used directly in a local-part. Otherwise the user part is equal to the local part.
;; QUOTE-CHARs are escaped to fit quoted form.
primary-c = primc-word *("." primc-word) Detailed Address
An email address which has a detail part.
primary-q = *(SAFEQ-CHAR / quoted) Primary Address
An email address which has no detail part, or the corresponding
address to a detailed address with the detail part removed.
primc-word = 1*SAFE-CHAR 3. Subaddressing Syntax
quoted = "\" QUOTE-CHAR A subaddress-aware final delivery agent divides the local-part into
two pieces separated by a "+". The user part is to the left of the
"+" and the detail part is to the right of the "+". A message with a
valid user part is delivered to the primary address by default,
regardless of the contents of the detail part. The detail part MAY
be used by final delivery filtering (e.g. to deliver messages with a
particular detail part into a special mailbox) or by an MUA.
subaddress = *(SAFEQ-CHAR / QUOTE-CHAR / "+") For example, the detailed address
;; This is the syntax for an unquoted subaddress. <delenn+grey-council@babylon5.example.org> might be used to send
;; If it fits canonical form (subaddress-c) it is email to <delenn@babylon5.example.org> relating to grey-council
;; used directly in a local-part. Otherwise business. Delenn can then direct her final delivery agent to file
;; QUOTE-CHARs are escaped to fit quoted form. messages with a "grey-council" subaddress into her "grey-council"
mailbox, perhaps with the [SIEVE-SUBADDRESS] extension.
subaddress-c = subc-word *("." subc-word) When generating a detailed address, the local part of the address
MUST be canonically quoted. A local part is canonically quoted if it
is legal according to both the formal grammer in [IMAIL] and the
formal grammar in [SMTP]. The following formal grammar restricts
<local-part> in this fashion and distinguishes the user part from the
detail part. Subaddress-aware MUAs MUST NOT generate addresses which
violate this syntax and subaddress-aware final delivery agents MAY
refuse to apply subaddress interpretation to addresses which violate
this syntax.
subaddress-q = *(SAFEQ-CHAR / "+" / quoted) local-part = local-quoted / local-unquoted
subc-word = 1*(SAFE-CHAR / "+") local-quoted = DQUOTE user-part-q ["+" detail-q] DQUOTE
QUOTE-CHAR = <"> / "\"
SAFE-CHAR = %21 / %23..27 / %2A / %2D / %2F..39 / %3D / local-unquoted = [user-part-c] ["+" [detail-c]]
%3F / %41..5A / %5E..7E
;; All printable US-ASCII characters except
;; space, plus "+" and <specials> as defined
;; in [IMAIL]
SAFEQ-CHAR = %20..21 / %23..2A / %2C..5B / %5D..7E user-part = *(SAFEQ-CHAR / QUOTE-CHAR)
;; All printable US-ASCII characters except ;; This is the syntax for an unquoted user-part
;; plus "+", quote <"> and backslash "\" ;; address. If it fits canonical form (user-part-c)
;; it is used directly in a local-part. Otherwise
;; QUOTE-CHARs are escaped to fit quoted form.
4. Subaddress Support Requirements user-part-c = userc-word *("." userc-word)
This section defines the requirements for subaddress aware final user-part-q = *(SAFEQ-CHAR / quoted)
delivery agents, gateway/firewalls, MUAs and mail list servers.
4.1. Final Delivery Agent Requirements userc-word = 1*SAFE-CHAR
A message with a valid primary address MUST be delivered to that quoted = "\" QUOTE-CHAR
primary address by default, regardless of the contents of the
subaddress. The subaddress MAY be used to route the message
according to rules specified by the owner of that primary address.
4.2. Gateway/Firewall Requirements detail-part = *(SAFEQ-CHAR / QUOTE-CHAR / "+")
;; This is the syntax for an unquoted subaddress.
;; If it fits canonical form (subaddress-c) it is
;; used directly in a local-part. Otherwise
;; QUOTE-CHARs are escaped to fit quoted form.
A subaddress aware gateway or firewall SHOULD preserve the detail-c = detailc-word *("." detailc-word)
subaddress when rewriting an address. A subaddress aware gateway
MAY rewrite an address into canonical quoted form.
4.3. MUA Requirements detail-q = *(SAFEQ-CHAR / "+" / quoted)
A subaddress aware MUA MUST allow the user to include a subaddress detailc-word = 1*(SAFE-CHAR / "+")
in the From header when sending a message. A subaddress aware MUA
MUST generate addresses in canonically quoted form following the
syntax for local-part in this specification. A subaddress aware
MUA SHOULD allow the user to include a subaddress in the envelope
sender address (as used in the SMTP MAIL FROM command). A
subaddress aware MUA which validates local addresses MUST ignore
subaddresses for the purposes of such validation.
4.4. Mail List Server Requirements QUOTE-CHAR = DQUOTE / "\"
A subaddress aware mail list server MUST allow users to subscribe SAFE-CHAR = %x21 / %x23-27 / %x2A / %x2D / %x2F-39 / %x3D /
using a subaddress. If such a server restricts postings by their %x3F / %x41-5A / %x5E-7E
envelope sender, sender or from address, it MUST ignore ;; All printable US-ASCII characters except
subaddresses for the purposes of such restrictions. ;; space, plus "+" and <specials> as defined
;; in [IMAIL]
5. Security Considerations SAFEQ-CHAR = %x20-21 / %x23-2A / %x2C-5B / %x5D-7E
;; All printable US-ASCII characters except
;; plus, quote and backslash.
If a final delivery agent executes a command line containing the 4. Subaddress Support Requirements
delivery address and the subaddress contains meta-characters with
special meaning to the command line interpretor this could result
in a serious security violation. In order to avoid this problem,
the final delivery agent MUST verify the subaddress contains no
characters with special meaning to the command line interpretor,
not use a command line interpretor, or strip the subaddress from
the address prior to generating the command line when it contains
characters with special meaning.
If a final delivery agent were to automatically create a folder This section defines the requirements for subaddress aware final
based on the subaddress, this could result in a denial of service delivery agents, gateway/firewalls, MUAs and mail list servers.
problem as well as placing control of a user's folder namespace in
the hands of outsiders. In order to avoid this problem, final
delivery agents MUST NOT automatically create new folders based on
the subaddress without explicit permission from the owner of the
primary address. Final delivery agents SHOULD NOT automatically
file a message into a folder based on the subaddress without
explicit permission from the owner of the primary address.
6. References 4.1. Final Delivery Agent Requirements
[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: By default, delivery to a detailed address MUST be identical to
ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt delivery to the primary address. Configuration MAY be used to
override behaviour for specific detailed addresses.
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text If [SIEVE] is supported by the delivery agent, then
Messages", RFC 822, University of Delaware, August 1982. [SIEVE-SUBADDRESS] MUST be supported.
<ftp://ds.internic.net/rfc/rfc822.txt> 4.2. Gateway/Firewall Requirements
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version A subaddress-aware gateway or firewall SHOULD preserve the detail
4rev1", RFC 2060, University of Washington, December 1996. part when rewriting an address. A subaddress aware gateway MAY
rewrite an address into canonical quoted form.
<ftp://ds.internic.net/rfc/rfc2060.txt> 4.3. MUA Requirements
[MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles A subaddress-aware MUA MUST allow the user to include a detail part
and Functions", RFC 2142, Internet Mail Consortium, May 1997. in the From header when sending a message. A subaddress-aware MUA
MUST generate addresses in canonically quoted form following the
syntax for local-part in this specification. A subaddress-aware MUA
SHOULD allow the user to user a detailed address as the envelope
sender address (as used in the SMTP MAIL FROM command). A
subaddress-aware MUA which validates local addresses MUST ignore
detail parts for the purposes of such validation.
<ftp://ds.internic.net/rfc/rfc2142.txt> 4.4. Mailing List Server Requirements
[SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, A subaddress-aware mailing list server MUST allow users to subscribe
Information Sciences Institute, August 1982. using a detailed address. If such a server restricts postings by
their envelope sender, Sender or From address, it MUST be able to be
configured, by the subscriber, to ignore detail parts for the
purposes of such restrictions.
<ftp://ds.internic.net/rfc/rfc821.txt> Mailing list servers SHOULD provide a per-user configuration setting
to allow for alternate delimiters, such as "-".
7. Author's Address 5. Security Considerations
Chris Newman If a final delivery agent executes a command line containing the
Innosoft International, Inc. delivery address and the detail part contains meta-characters with
1050 Lakes Drive special meaning to the command line interpretor this could result in
West Covina, CA 91790 USA a serious security violation. In order to avoid this problem, the
final delivery agent MUST verify the detail part contains no
characters with special meaning to the command line interpretor, not
use a command line interpretor, or strip the detail part from the
address prior to generating the command line when it contains
characters with special meaning.
Email: chris.newman@innosoft.com If a final delivery agent were to automatically create a mailbox
based on the detail part, this could result in a denial of service
problem as well as placing control of a user's mailbox namespace in
the hands of outsiders. In order to avoid this problem, final
delivery agents MUST NOT automatically create new mailboxes based on
the detail part without explicit permission from the owner of the
primary address. Final delivery agents SHOULD NOT automatically file
a message into a mailbox based on the subaddress without explicit
configuration from the owner of the primary address.
Appendix A. Subaddress Scenarios Detailed addresses themselves may be used as a weak form of
authorization token, for example in the scenario given in
Appendix A.6. In such cases, acquisition of the token by a third
party may aid in fraud. Therefore such subaddresses MUST be random,
and MUST NOT be disclosed.
This appendix includes examples of how subaddresses are used on the 6. Acknowledgements
Internet today.
A.1. Subscribe to Mailing List by Subaddress This draft is a direct ancestor of a 1997 draft by Chris Newman.
Some usages documented herein may reflect this long heritage, however
it has been updated with current usages, including the use of
subaddressing as an anti-phishing technique described by John Klensin
on the IETF mailing list. No existing usages had fallen out of
fashion in the intervening decade.
Many users (including the author of this specification) subscribe Discussions within the SIEVE working group also influenced the
to mailing lists using a subaddress and use the final delivery changes to the draft - in particular, the terminology has been
agent to file all messages from that mailing list into a different changed to match that of [SIEVE-SUBADDRESS].
incoming folder based on the subaddress. This sorts mailing list
traffic into appropriate folders with 100% accuracy and without
scanning the contents of the message headers.
A.2. User Controlled Distribution Lists 7. References
Some final delivery agents allow a user to set up a distribution 7.1. Normative References
list and associate it with a particular subaddress. This permits
users to manage their own distribution lists without administrative
intervention.
A.3. Mailto URL Indicator [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
By including a different subaddress for each mailto URL on a web [IMAIL] Resnick, P., "Internet Message Format", RFC 2822,
page, a user can determine which mailto URL was selected for a April 2001.
particular message.
A.4. Support for Special Addresses [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
A user may forward mail from special purpose addresses, such as [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering
those described in [MBOX-NAMES] to a subaddress of their primary Language", draft-ietf-sieve-3028bis-13 (work in progress),
account. This avoids the need to login as multiple users while October 2007.
still keeping the mail separated.
A.5. Priority Categorization [SIEVE-SUBADDRESS]
Murchison, K., "Sieve Email Filtering -- Subaddress
Extension", draft-ietf-sieve-rfc3598bis-05 (work in
progress), June 2006.
A user may advertise different subaddresses to different audiences [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
and prioritize reading them appropriately. For example, one of the April 2001.
current esteemed area directors uses an "iesg" subaddress to
prioritize IESG traffic separately from regular email. 7.2. Informative References
[MAIL-ARCH]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-09 (work in progress), May 2007.
[MBOX-NAMES]
Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.
[MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
Appendix A. Subaddressing Scenarios
This appendix includes examples of how subaddressing used on the
Internet today.
A.1. Subscribe to Mailing List by Detailed Address
Many users subscribe to mailing lists using a detailed address and
use the final delivery agent to file all messages from that mailing
list into a different incoming mailbox based on the detail part.
This sorts mailing list traffic into appropriate mailboxes with 100%
accuracy and without scanning the contents of the message headers.
A.2. User Controlled Distribution Lists
Some final delivery agents allow a user to set up a distribution list
and associate it with a particular detailed address. This permits
users to manage their own distribution lists without administrative
intervention.
A.3. Mailto URL Indicator
By including a different detail part for each mailto URL on a web
page, a user can determine which mailto URL was selected for a
particular message.
A.4. Support for Special Addresses
A user may forward mail from special purpose addresses, such as those
described in [MBOX-NAMES] to a subaddress of their primary account.
This avoids the need to login as multiple users while still keeping
the mail separated.
A.5. Priority Categorization
A user may advertise different detailed addresses to different
audiences and prioritize reading them appropriately. For example,
one of the current esteemed area directors uses an "ietf" detail part
to prioritize IETF traffic separately from regular email.
A.6. Anti-Phishing
If a user provides their bank with a unique detailed address, then
any messages arriving either to the primary address or to a different
detailed address are more easily detirmined to be fraudulent, and can
be easily filtered out.
This effectively uses the detailed address as a weak authorization
token, so it is advisable to choose a random or unusual detail part.
Appendix B. Open Issues and Discussion
This section will hopefully be empty prior to publication as an RFC.
The author is aware of two main areas of contention which stalled the
original document. Firstly, the choice of subaddress delimiter
character is not universal, nor even the choice of having one at all.
Unfortunately, a choice must be made for interoperability, therefore
the plus character remains specified by this document, being the most
common case.
Secondly, the recommendation in Section 4.4 effectively means that
mailing list management software is encouraged into interpreting the
local-part of addresses in foreign domains. This recommendation has
been reduced in this version - to requiring that the ability be
present, and possible to configure by the subscriber. It is the
author's assertion that modern mailing list management software is
typically able to be configured by the subscriber in many ways
already, so this ought to settle contention.
B.1. To-do
This is likely to break [MIXER] - either a solution or advice will be
needed here.
Need to switch to and use terminology within [MAIL-ARCH], rather than
defining potentially clashing terminology.
Author's Address
Dave Cridland
Isode Limited
5 Castle Business Village
36, Station Road
Hampton, Middlesex TW12 2BX
GB
Email: dave.cridland@isode.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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.
Intellectual Property
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.
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 75 change blocks. 
202 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/