< draft-ietf-vpim-hint-07.txt		draft-ietf-vpim-hint-08.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group E. Burger		RFC 3458
	Internet Draft SnowShore Networks
	Document: draft-ietf-vpim-hint-07.txt E. Candell
	Category: Standards Track Comverse
	Expires December 2001 C. Eliot
	Microsoft Corporation
	G. Klyne
	Baltimore Technologies
	June 5, 2001
	Message Context for Internet Mail
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [1].
	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.
	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."
	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 document is a work product of the IETF Voice Profile for
	Internet Mail (VPIM) Work Group.
	1. Abstract
	This memo describes a new RFC2822 message header, "Message-Context".
	This header provides information about the context and presentation
	characteristics of a message.
	A receiving user agent (UA) may use this information as a hint to
	optimally present the message.
	Table of Contents
	1. Abstract...........................................................1
	2. Introduction.......................................................3
	3. Conventions used in this document..................................3
	4. Motivation.........................................................4
	5. Functional Requirements............................................5
	6. Determining the Message Context....................................6
	7. Message-Context Reference Field....................................7
	7.1. Message-Context Syntax...........................................7
	7.2. message-context-class Syntax.....................................7
	7.2.1. voice-message..................................................8
	7.2.2. fax-message....................................................8
	7.2.3. pager-message..................................................8
	7.2.4. multimedia-message.............................................8
	7.2.5. text-message...................................................8
	7.2.6. none...........................................................9
	8. Security Considerations............................................9
	9. IANA Considerations................................................9
	9.1. Message Content Type Registrations..............................10
	9.2. Registration Template...........................................10
	9.3. Message-Context Registration....................................11
	10. APPENDIX: Some messaging scenarios...............................11
	10.1. Internet e-mail................................................11
	10.2. Pager service..................................................12
	10.3. Facsimile......................................................13
	10.4. Voice mail.....................................................13
	10.5. Multimedia message.............................................13
	11. References.......................................................14
	12. Acknowledgments..................................................15
	13. Author's Addresses...............................................15
	14. Full Copyright Statement.........................................17
	2. Introduction
	This document describes a mechanism to allow senders of an Internet
	mail message to convey the message's contextual information. Taking
	account of this information, the receiving user agent (UA) can make
	decisions that improve message presentation for the user in the
	context the sender and receiver expects.
	In this document, the "message context" conveys information about
	the way the user expects to interact with the message. For example,
	a message may be e-mail, voice mail, fax mail, etc. A smart UA may
	have specialized behavior based on the context of the message.
	This document specifies a RFC2822 header called "Message-Context".
	The mechanism is in some ways similar to the use of the Content-
	Disposition MIME entity described in [2]. Content-Disposition gives
	clues to the receiving User Agent (UA) for how to display a given
	body part. Message-Context can give clues to the receiving UA for
	the presentation of the message. This allows the receiving UA to
	present the message in a meaningful and helpful way to the
	recipient.
	Typical uses for this mechanism include:
	o Selecting a special viewer for a given message.
	o Selecting an icon indicating the kind of message in a displayed
	list of messages.
	o Arranging messages in an inbox display.
	o Filtering messages the UA presents when the user has limited
	access.
	3. Conventions used in this document
	This document refers generically to the sender of a message in the
	masculine (he/him/his) and the recipient of the message in the
	feminine (she/her/hers). This convention is purely for convenience
	and makes no assumption about the gender of a message sender or
	recipient.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC-2119 [3].
	FORMATTING NOTE: Notes, such at this one, provide additional
	nonessential information that the reader may skip without missing
	anything essential. The primary purpose of these non-essential
	notes is to convey information about the rationale of this document,
	or to place this document in the proper historical or evolutionary
	context. Readers whose sole purpose is to construct a conformant
	implementation may skip such information. However, it may be of use
	to those who wish to understand why we made certain design choices.
	4. Motivation
	Multimedia messaging systems receive messages that a UA may present
	in variety of ways. For example, traditional e-mail uses simple
	text messages that the recipient displays and edits. One UA may
	automatically print Fax images. Another UA may play voice messages
	through a telephone handset. Likewise, a receiving desktop computer
	may process or present documents transferred over e-mail using a
	local application. Emerging and future developments may deliver
	other forms of information that have their own characteristics for
	user presentation, such as video messages and pager messages.
	An often-requested characteristic for multimedia messaging systems
	is to collect received messages in a "universal inbox", and to offer
	them to the user as a combined list.
	In the context of "unified messaging", different message contexts
	may have different implied semantics. For example, some users may
	perceive voicemail to have an implicit assumption of urgency. Thus
	they may wish to gather them together and process them before other
	messages. This results in the end-user receiving agent needing to
	be able to identify voicemail and distinguish it from other
	messages.
	The uses of this kind of presentation characteristic for each
	message is multi-fold:
	o Display an indication to the user (e.g., by a suitably
	evocative icon along with other summary fields),
	o Auto-forward a given message type into another messaging
	environment (e.g., a page to a mobile short message service),
	o Prioritize and group messages in an inbox display list,
	o Suggest appropriate default handling for presentation,
	o Suggest appropriate default handling for reply, forward, etc.,
	and
	A problem faced by multimedia messaging systems is that it is not
	always easy to decide the context of a received message. For
	example, consider the following scenarios.
	o A message that contains audio and image data: Is this a fax
	message that happens to have some voice commentary? Is it a
	voice message that is accompanied by some supplementary
	diagrams? Is it a fully multimedia message, in which all parts
	are expected to carry equal significance?
	o A message containing text and audio data: Is this e-mail with
	an MP3 music attachment? Is it a voice message that happens to
	have been generated with an initial text header for the benefit
	of non-voice-enabled e-mail receivers?
	The message context does relate to the message media content.
	However, it is not the same thing. As shown above, the media type
	used in a message is not sufficient to indicate the message context.
	One cannot determine a priori which media types to use in
	alternative (gateway) message. Also, what if the user cares about
	distinguishing traditional e-mail text from SMS messages? They are
	both the same media type, text, but they have different user
	contexts.
	5. Functional Requirements
	The goals stated above lead to the following functional
	requirements.
	For receivers:
	o Identify a message as belonging to a message class.
	o Incorrect or invalid message classification must not result in
	failure to transfer or inability to present a message.
	For senders:
	o Specify message classes by the originating user's choice of
	authoring tool or simple user interaction.
	For both:
	o Specify a well-defined set of message classes to make
	interoperability between mail user agents (UAs) possible.
	o Message classification information has to be interpretable in
	reasonable fashion by many different user agent systems.
	o The mechanism should be extensible to allow for the
	introduction of new kinds of messages.
	NOTE: We specifically do not specify user agent behavior when the
	user agent forwards a message. Clearly, the user agent, being
	message-context-aware, should provide a meaningful message-context.
	It is obvious what to do for the easy cases. Messages that the user
	simply forwards will most likely keep the context unchanged.
	However, it is beyond the scope of this document to specify the user
	agent behavior for any other scenario.
	6. Determining the Message Context
	One method of indicating the interpretation context of a message is
	to examine the media types in the message. However, this requires
	the UA to scan the entire message before it can make this
	determination. This approach is particularly burdensome for the
	multi-media mail situation, as voice and especially video mail
	objects are quite large.
	We considered indicating the message context by registering a
	multipart/* MIME subtype (Content-Type). For example, the VPIM Work
	Group has registered multipart/voice-message to indicate that a
	message is primarily voice mail [4]. However, multipart/voice-
	message is identical in syntax to multipart/mixed. The only
	difference is that VPIM mail transfer agents and user agents
	recognize that they can perform special handling of the message
	based on it being a voice mail message. Moreover, Content-Type
	refers to a given MIME body part, not to the message as a whole.
	We wish to avoid scanning the entire message. In addition, we wish
	to avoid having to create multiple aliases for multipart/mixed every
	time someone identifies a new primary content type. Multiple
	aliases for multipart/mixed are not desirable as they remove the
	possibility for specifying a message as multipart/alternate,
	multipart/parallel, or multipart/encrypted, for example.
	Since the message context is an attribute of the entire message, it
	is logical to define a new top-level (RFC2822 [5]) message
	attribute. To this end, this document introduces the message
	attribute "Message-Context".
	Message-Context only serves to identify the message context. It
	does not provide any indication of content that the UA must be
	capable of delivering. It does not imply any message disposition or
	delivery notification. There is a related effort to define Critical
	Content of Internet Mail [6] that one might use to perform these
	tasks.
	Message-Context is only an indicator. We do not intend for it to
	convey information that is critical for presentation of the message.
	One can conceive of goofy situations, such as a message marked
	"voice-message" but without an audio body part. In this case, the
	fact that the contents of a message donÆt match its context does not
	mean the receiving system should generate an error report or fail to
	deliver or process the message.
	7. Message-Context Reference Field
	The Message-Context reference field is a top-level header inserted
	by the sending UA to indicate the context of the message.
	A receiving user agent MUST NOT depend on the indicated message-
	context value in a way that prevents proper presentation of the
	message. If the value is incorrect or does not match the message
	content, the receiving user agent MUST still be capable of
	displaying the message content at least as meaningfully as it would
	if no Message-Context value were present.
	One can envision situations where a well-formed message ends up not
	including a media type one would expect from the message-context.
	For example, consider a voice messaging system that records a voice
	message and also performs speech-to-text processing on the message.
	The message then passes through a content gateway, such as a
	firewall, that removes non-critical body parts over a certain
	length. The receiving user agent will receive a message in the
	voice-message context that has only a text part and no audio. Even
	though the message does not have audio, it is still in the voice
	message context.
	Said differently, the receiving UA can use the message-context to
	determine whether, when, and possibly where to display a message.
	However, the message-context should not affect the actual rendering
	or presentation. For example, if the message is in the voice-
	message context, then don't try to send it to a fax terminal.
	Conversely, consider the case of a message in the voice-message
	context that gets delivered to a multimedia voice terminal with a
	printer. However, this message only has fax content. In this
	situation, the "voice-message" context should not stop the terminal
	from being properly rendering the message.
	7.1. Message-Context Syntax
	The syntax of the Message-Context field, described using the ABNF
	[7] is as follows. Note that the Message-Context header field name
	and message-context-class values are not case sensitive.
	"Message-Context" ":" message-context-class CRLF
	7.2. message-context-class Syntax
	The message-context-class indicates the context of the message.
	This is an IANA registered value. Current values for message-
	context-class are as follows.
	message-context-class = ( "voice-message"
	| "fax-message"
	| "pager-message"
	| "multimedia-message"
	| "text-message"
	| "none"
	| extension-type )
	extension-type = token ; Defined and registered per Section 8
	/ vnd.token ; Experimental, private use
	token = <syntax as defined by [8],
	but not starting with the characters "vnd.">
	vnd.token = <Vendor-specific, private token>
	Note: The values for Message-Context must be either IANA registered
	values or experimental, vendor tokens. This ensures that user
	agents from different vendors will interoperate and perform in a
	uniform manner without an undue burden on the vendors.
	7.2.1. voice-message
	The voice-message class states the message is a voice mail message.
	7.2.2. fax-message
	The fax-message class states the message is a facsimile mail
	message.
	7.2.3. pager-message
	The pager-message class states the message is a page, such as a text
	or numeric pager message or a traditional short text message service
	(SMS) message.
	7.2.4. multimedia-message
	The multimedia-message class states the message is an aggregate
	multimedia message, such as a message specified by [9]. This helps
	identify a message in a multimedia context. For example, a MIME
	multipart/related [10] data part and resource part looks the same as
	a multimedia MHTML multipart/related. However, the semantics are
	quite different.
	7.2.5. text-message
	The text-message class states the message is a traditional internet
	mail message. Such a message consists of text, possibly richly
	formatted, with or without attachments.
	7.2.6. none
	The none class states there is no context information for this
	message.
	If a message has no Message-Context reference field, a receiving
	user agent MUST treat it the same as it would if the message has a
	"none" value.
	8. Security Considerations
	The intention for this header is to be an indicator only of message
	context. One can imagine someone creating an "Application" Message-
	Context. A poorly designed user agent could blindly execute a
	mailed program based on the Message-Context. Don't do that!
	One can envision a denial of service attack by bombing a receiver
	with a message that has a Message-Context that doesn't fit the
	profile of the actual body parts. This is why the receiver
	considers the Message-Context to be a hint only.
	9. IANA Considerations
	Section 9.3 is a registration for a new top-level RFC2822 [5]
	message header, "Message-Context".
	This document creates an extensible set of context types. To
	promote interoperability and coherent interpretations of different
	types, we need a central repository for well-known context types.
	IANA will create a repository for context types called "Internet
	Message Context Types". Following the policies outlined in [11],
	this repository is "Specification Required" by RFC. Section 9.1
	describes the initial values for this registry.
	To create a new message context type, you MUST publish an RFC to
	document the type. In the RFC, include a copy of the registration
	template found in Section 9.2 of this document. Put the template in
	your IANA Considerations section, filling-in the appropriate fields.
	You MUST describe any interoperability and security issues in your
	draft.
	9.1. Message Content Type Registrations
	Internet Message Content Types
	==============================
	Value Description Reference
	----- ----------- ---------
	voice-message Indicates a message whose primary This RFC
	content is a voice mail message. The
	primary content is audio data. The
	context is usually a message recorded
	from a voice telephone call.
	fax-message Indicates a message whose primary This RFC
	content is a fax mail message. The
	primary content is image data. The
	context is usually a message recorded
	from a facsimile telephone call.
	pager-message Indicates a message whose primary This RFC
	content is a page. The primary
	content is text data. The context is
	an urgent message usually of a
	limited length.
	multimedia-message Indicates a message whose primary This RFC
	content is a multimedia message. The
	primary content is multimedia, most
	likely MHTML. The context is often
	spam or newsletters.
	text-message Indicates a classic, text-based, This RFC
	Internet message.
	None Indicates an unknown message context. This RFC
	9.2. Registration Template
	In the following template, a pipe symbol, "|", precedes instructions
	or other helpful material. Be sure to replace "<classname>" with
	the class name you are defining.
	Message-Context class name:
	<classname>
	Summary of the message class:
	| Include a short (no longer than 4 lines) description or summary
	| Examples:
	| "Palmtop devices have a 320x160 pixel display, so we can..."
	| "Color fax is so different than black & white that..."
	Person & email address to contact for further information:
	| Name & e-mail
	9.3. Message-Context Registration
	To: iana@iana.org
	Subject: Registration of New RFC 2822 Header
	RFC 2822 Header Name:
	Message-Context
	Allowable values for this parameter:
	Please create a new registry for Primary Context Class
	registrations. See section 9.1 of this document for the initial
	values.
	RFC 2822 Section 3.6 Repeat Value:
	Field Min Number Max Number Notes
	Message-Context 0 1
	Person & email address to contact for further information:
	Eric Burger
	e.burger@ieee.org
	10. APPENDIX: Some messaging scenarios
	This section is not a normative part of this document. We include
	it here as a historical perspective on the issue of multimedia
	message types.
	These scenarios are neither comprehensive nor fixed. For example,
	e-mails being typically text-based do not mean that they cannot
	convey a voice-message. This very mutability serves to underline
	the desirability of providing some explicit message context hint.
	10.1. Internet e-mail
	Internet e-mail carries textual information. Sometimes it conveys
	computer application data of arbitrary size.
	Typically, one uses e-mail for non-urgent messages, which the
	recipient will retrieve and process at a time convenient to her.
	The normal device for receiving and processing e-mail messages is
	some kind of personal computer. Modern personal computers usually
	come with a reasonably large display and an alphanumeric keyboard.
	Audio, video, and printing capabilities are not necessarily
	available.
	One can use E-mail for communication between two parties (one-to-
	one), a small number of known parties (one-to-few) or, via an e-mail
	distribution list, between larger numbers of unknown parties (one-
	to-many).
	One of the endearing characteristics of e-mail is the way that it
	allows the recipient to forward all or part of the message a to
	another party, with or without additional comments. It is quite
	common for an e-mail to contain snippets of content from several
	previous messages. Similar features apply when replying to e-mail.
	10.2. Pager service
	One uses a pager message to convey notifications and alerts. For
	the most part, these notifications are textual information of
	limited size. The typical limit is 160 characters. People use
	pages for relatively urgent messages, which the sender wishes the
	receiver to see and possibly respond to within a short time period.
	Pager messages are often used as a way of alerting users to
	something needing their attention. For example, a system can use a
	page to notify a subscriber there is a voicemail message requiring
	her attention.
	Example devices for sending and receiving a pager message are a
	mobile telephone with a small character display or a text pager.
	Personal computers and personal digital assistants (PDAs) can also
	participate in pager messaging.
	Currently, the most common use of pager messages are between just
	two parties (one-to-one).
	One delivery method for pager messages is the short text messaging
	service (SMS). SMS is a facility that has evolved for use with
	mobile telephones, and has an associated per-message transmission
	charge. Note that the focus here is on the notification aspect of
	SMS. From the beginning, SMS was envisioned to be more than a
	simple pager service. Operators can use SMS to provision the phone,
	for example. From the subscriber point of view, SMS has evolved
	considerably from its origins as a pure pager replacement service.
	For example, with mobile originate service, people can have two-way
	text chat sessions using SMS and a mobile phone. In addition, there
	are SMS-enabled handsets that can display pictures. However, for
	the purposes of this document, there is still a need to capture the
	essence of a "highly urgent, short-text, notification or alert"
	service.
	Users often send pager messages in isolation, rather than as part of
	a longer exchange. One use for them is as a prompt or invitation to
	communicate by some more convenient and content-rich method, such as
	a telephone call.
	10.3. Facsimile
	People use facsimile to convey image information of moderate size,
	typically a small number of pages. Sometimes people use facsimile
	for larger documents.
	Facsimile is a facility that usually uses circuit-switched telephone
	circuits, with connection-time charges. Message transfer takes
	place in real-time. Thus, people often use facsimile for urgent
	communication.
	The normal device for sending and receiving a facsimile is a self-
	contained scanning and printing device connected to a telephone line
	or a desktop computer.
	Most facsimiles are between just two parties (one-to-one). However,
	a significant portion of facsimile service is broadcast between
	multiple parties (one-to-many).
	Most facsimile exchanges are in isolation, rather than as part of a
	longer exchange. Facsimile data is typically not suitable for
	further processing by computer.
	10.4. Voice mail
	People use voice mail to convey audio information, almost
	exclusively human speech.
	Voice mail is a facility that usually uses circuit-switched
	telephone circuits, with modest connection-time charges, often used
	for moderately urgent messages. A common use for them is as a
	prompt or invitation to communicate by some more convenient method,
	such as a telephone call. In most, but not all cases, the sender of
	a voice message does not want to send a message at all. Rather,
	they wished to engage in a real-time conversation.
	The normal device for sending and receiving a voice mail is a
	telephone handset.
	Voice messages are usually sent between just two parties (one-to-
	one).
	Voice mail data is not generally suitable for further processing by
	computer.
	10.5. Multimedia message
	We define a multimedia message as a message containing more than one
	basic media type (text, image, audio, video, model, application).
	The following are some characteristics of a multimedia message.
	In some cases, a multimedia message is just e-mail with an
	attachment that a multimedia display application presents. For
	example, I can send you an MP3 of something I recorded in my garage
	today.
	In other cases, a multimedia message represents a convergence
	between two or more of the scenarios described above. For example,
	a voice message with an accompanying diagram or a talking head video
	message is a multimedia message.
	The characteristics will vary somewhat with the intent of the
	sender. This in turn may affect the user agent or application used
	to render the message.
	11. References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.
	2 Troost, R., Dorner, S., and Moore, K., "Communicating
	Presentation Information in Internet Messages: The Content-
	Disposition Header Field", RFC 2183, New Century Systems,
	QUALCOMM Incorporated, and University of Tennessee, August 1997.
	3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	4 Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type
	Registration", RFC 2423, Lucent Technologies and Northern
	Telecom, September 1998.
	5 Resnick, P., "Internet Message Format", RFC 2822, Qualcomm, April
	2001.
	6 Burger, E., "Critical Content of Internet Mail", draft-ietf-vpim-
	cc-04.txt, Work in Progress.
	7 Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, Internet Mail Consortium and
	Demon Internet Ltd., November 1997.
	8 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message Bodies",
	RFC 2045, Innosoft and First Virtual, November 1996.
	9 Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of
	Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm
	University/KTH, Microsoft, and Lotus Development Corporation,
	March 1999.
	10 Levinson, E., "The MIME Multipart/Related Content-type", RFC
	2387, August 1998.
	11 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	12. Acknowledgments
	Many of the ideas here arose originally from a discussion with Jutta
	Degener.
	We'd also like to thank Keith Moore for helping us tighten-up our
	explanations.
	In the last round, we got some rather good advise from Caleb Clausen
	and Dave Aronson.
	Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae
	helped distil the essence of the pager service vis a vis SMS.
	We offer an extra special thanks to Greg Vaudreuil for pulling RFC
	2557 out of his hat.
	13. Author's Addresses
	Eric Burger
	SnowShore Networks, Inc.
	285 Billerica Rd.
	Chelmsford, MA 01824-4120
	USA
	Phone: +1 978 367 8403		Title: Message Context for Internet Mail
	Fax: +1 603 457 5944		Author(s): E. Burger, E. Candell, C. Eliot, G. Klyne
	Email: e.burger@ieee.org		Status: Standards Track
			Date: January 2003
			Mailbox: e.burger@ieee.org, emily.candell@comverse.com,
			GK@ACM.ORG, charle@Microsoft.com
			Pages: 17
			Characters: 34181
			Updates/Obsoletes/SeeAlso: None
	Emily Candell		I-D Tag: draft-ietf-vpim-hint-08.txt
	Comverse Network Systems
	200 Quannapowitt Pkwy.
	Wakefield, MA 01880
	USA
	Phone: +1 781 213 2324		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3458.txt
	Email: emily.candell@comverse.com
	Graham Klyne
	Baltimore Technologies Ltd.
	1310 Waterside
	Arlington Business Park
	Theale
	Reading, RG7 4SA
	United Kingdom
	Telephone: +44 118 930 8000		This memo describes a new RFC 2822 message header, "Message-Context".
	Facsimile: +44 118 930 9000		This header provides information about the context and presentation
	E-mail: GK@ACM.ORG		characteristics of a message.
	Charles Eliot		A receiving user agent (UA) may use this information as a hint to
	Microsoft Corporation		optimally present the message.
	One Microsoft Way
	Redmond WA 98052
	USA
	Telephone: +1 425 936 9760		This document is a product of the Voice Profile for Internet Mail
	E-Mail: charle@Microsoft.com		Working Group of the IETF.
	14. Full Copyright Statement		This is now a Proposed Standard Protocol.
	The IETF takes no position regarding the validity or scope of any		This document specifies an Internet standards track protocol for
	intellectual property or other rights that might be claimed to		the Internet community, and requests discussion and suggestions
	pertain to the implementation or use of the technology described in		for improvements. Please refer to the current edition of the
	this document or the extent to which any license under such rights		"Internet Official Protocol Standards" (STD 1) for the
	might or might not be available; neither does it represent that it		standardization state and status of this protocol. Distribution
	has made any effort to identify any such rights. Information on the		of this memo is unlimited.
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication 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 Secretariat.
	The IETF invites any interested party to bring to its attention any		This announcement is sent to the IETF list and the RFC-DIST list.
	copyrights, patents or patent applications, or other proprietary		Requests to be added to or deleted from the IETF distribution list
	rights that may cover technology that may be required to practice		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	this standard. Please address the information to the IETF Executive		added to or deleted from the RFC-DIST distribution list should
	Director.		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) 2001 The Internet Society. All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it		Subject: getting rfcs
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Requests for special distribution should be addressed to either the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		specifically noted otherwise on the RFC itself, all RFCs are for
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		unlimited distribution.echo
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		Submissions for Requests for Comments should be sent to
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 15 change blocks.
	756 lines changed or deleted		38 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/