< draft-crispin-imap-rfc2359bis-03.txt		draft-crispin-imap-rfc2359bis-04.txt >
	Network Working Group M. Crispin		Network Working Group M. Crispin
	Obsoletes: 2359		Obsoletes: 2359
	Document: internet-drafts/draft-crispin-imap-rfc2359bis-03.txt		Document: internet-drafts/draft-crispin-imap-rfc2359bis-04.txt
	Internet Message Access Protocol (IMAP) - UIDPLUS extension		Internet Message Access Protocol (IMAP) - UIDPLUS extension
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that		By submitting this Internet-Draft, each author represents that
	any applicable patent or other IPR claims of which he or she is		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		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		becomes aware will be disclosed, in accordance with Section 6 of
	BCP 79.		BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	A revised version of this document will be submitted to the RFC		A revised version of this document will be submitted to the RFC
	editor as an Informational Document for the Internet Community.		editor as an Informational Document for the Internet Community.
	A revised version of this draft document will be submitted to the RFC		A revised version of this draft document will be submitted to the RFC
	editor as a Proposed Standard for the Internet Community. Discussion		editor as a Proposed Standard for the Internet Community. Discussion
	and suggestions for improvement are requested, and should be sent to		and suggestions for improvement are requested, and should be sent to
	imapext@IMC.ORG. This document will expire before 24 November 2005.		imapext@IMC.ORG. This document will expire before 25 November 2005.
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Abstract		Abstract
	The UIDPLUS extension of the Internet Message Access Protocol [IMAP]		The UIDPLUS extension of the Internet Message Access Protocol [IMAP]
	provides a set of features intended to reduce the amount of time and		provides a set of features intended to reduce the amount of time and
	resources used by some client operations. The features in UIDPLUS		resources used by some client operations. The features in UIDPLUS
	are primarily intended for disconnected-use clients.		are primarily intended for disconnected-use clients.
	Conventions Used in this Document		Conventions Used in this Document
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are		"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are
	to be interpreted as described in [KEYWORDS].		to be interpreted as described in [KEYWORDS].
	A "UID set" is similar to the [IMAP] sequence set; however, the "*"		A "UID set" is similar to the [IMAP] sequence set; however, the "*"
	value for sequence number is not permitted.		value for sequence number is not permitted.
	Introduction and Overview		Introduction and Overview
	The UIDPLUS extension is present in any IMAP server implementation		The UIDPLUS extension is present in any IMAP server implementation
	which returns "UIDPLUS" as one of the supported capabilities to the		which returns "UIDPLUS" as one of the supported capabilities to the
	CAPABILITY command.		CAPABILITY command.
	The UIDPLUS extension defines an additional command. In addition,		The UIDPLUS extension defines an additional command. In addition,
	this document recommends new status response codes in IMAP which		this document recommends new status response codes in IMAP which
	SHOULD be returned by all server implementations, regardless of		SHOULD be returned by all server implementations, regardless of
	whether or not the UIDPLUS extension is implemented.		whether or not the UIDPLUS extension is implemented.
	The added facilities of the features in UIDPLUS are optimizations;		The added facilities of the features in UIDPLUS are optimizations;
	clients can provide equivalent functionality, albeit less		clients can provide equivalent functionality, albeit less
	efficiently, by using facilities in the base protocol.		efficiently, by using facilities in the base protocol.
	1. Additional Commands		1. Additional Commands
	The following command definition is an extension to [IMAP] section		The following command definition is an extension to [IMAP] section
	6.4.		6.4.
	1.1 UID EXPUNGE Command		1.1 UID EXPUNGE Command
	Arguments: sequence set		Arguments: sequence set
	Data: untagged responses: EXPUNGE		Data: untagged responses: EXPUNGE
	Result: OK - expunge completed		Result: OK - expunge completed
	NO - expunge failure (e.g., permission denied)		NO - expunge failure (e.g., permission denied)
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The UID EXPUNGE command permanently removes from the currently		The UID EXPUNGE command permanently removes from the currently
	selected mailbox all messages that both have the \Deleted flag set		selected mailbox all messages that both have the \Deleted flag set
	and have a UID that is included in the specified sequence set. If		and have a UID that is included in the specified sequence set. If
	a message either does not have the \Deleted flag set or has a UID		a message either does not have the \Deleted flag set or has a UID
	that is not included in the specified sequence set, it is not		that is not included in the specified sequence set, it is not
	affected.		affected.
	This command may be used to ensure that a replayed EXPUNGE command		This command may be used to ensure that a replayed EXPUNGE command
	does not remove any messages that have been marked as \Deleted		does not remove any messages that have been marked as \Deleted
	between the time that the user requested the expunge operation and		between the time that the user requested the expunge operation and
	the time the server processes the command.		the time the server processes the command.
	If the server does not support the UIDPLUS capability, the client		If the server does not support the UIDPLUS capability, the client
	should fall back to using the STORE command to temporarily remove		should fall back to using the STORE command to temporarily remove
	the \Deleted flag from messages it does not want to remove. The		the \Deleted flag from messages it does not want to remove. The
	client could alternatively fall back to using the EXPUNGE command,		client could alternatively fall back to using the EXPUNGE command,
	risking the unintended removal of some messages.		risking the unintended removal of some messages.
	Example: C: A003 UID EXPUNGE 3000:3002		Example: C: A003 UID EXPUNGE 3000:3002
	S: * 3 EXPUNGE		S: * 3 EXPUNGE
	S: * 3 EXPUNGE		S: * 3 EXPUNGE
	S: * 3 EXPUNGE		S: * 3 EXPUNGE
	S: A003 OK UID EXPUNGE completed		S: A003 OK UID EXPUNGE completed
	2. Additional Response Codes		2. Additional Response Codes
	The following response codes are extensions to the response codes		The following response codes are extensions to the response codes
	defined in [IMAP] section 7.1. With limited exceptions, discussed		defined in [IMAP] section 7.1. With limited exceptions, discussed
	below, server implementations that advertise the UIDPLUS extension		below, server implementations that advertise the UIDPLUS extension
	SHOULD return these response codes.		SHOULD return these response codes.
	In the case of a mailbox which has permissions set so that the client		In the case of a mailbox which has permissions set so that the client
	can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the		can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the
	server SHOULD NOT send an APPENDUID or COPYUID response code as it		server SHOULD NOT send an APPENDUID or COPYUID response code as it
	would disclose information about the mailbox.		would disclose information about the mailbox.
	In the case of a mailbox that has UIDNOTSTICKY status (as defined		In the case of a mailbox that has UIDNOTSTICKY status (as defined
	below), the server MAY omit the APPENDUID or COPYUID response code as		below), the server MAY omit the APPENDUID or COPYUID response code as
	it is not meaningful.		it is not meaningful.
	If the server does not return the APPENDUID or COPYUID response		If the server does not return the APPENDUID or COPYUID response
	codes, the client can discover this information by selecting the		codes, the client can discover this information by selecting the
	destination mailbox. The location of messages placed in the		destination mailbox. The location of messages placed in the
	destination mailbox by COPY or APPEND can be determined by using		destination mailbox by COPY or APPEND can be determined by using
	FETCH and/or SEARCH commands (e.g. for Message-ID or some unique		FETCH and/or SEARCH commands (e.g. for Message-ID or some unique
	marker placed in the message in an APPEND).		marker placed in the message in an APPEND).
	APPENDUID		APPENDUID
	Followed by the UIDVALIDITY of the destination mailbox and the		Followed by the UIDVALIDITY of the destination mailbox and the
	UID assigned to the appended message in the destination mailbox,		UID assigned to the appended message in the destination mailbox,
	indicates that the message has been appended to the destination		indicates that the message has been appended to the destination
	mailbox with that UID.		mailbox with that UID.
	If the server also supports the [MULTIAPPEND] extension, and if		If the server also supports the [MULTIAPPEND] extension, and if
	multiple messages were appended in the APPEND command, then the		multiple messages were appended in the APPEND command, then the
	second value is a UID set containing the UIDs assigned to		second value is a UID set containing the UIDs assigned to
	the appended messages, in the order they were transmitted in the		the appended messages, in the order they were transmitted in the
	APPEND command. This UID set may not contain extraneous		APPEND command. This UID set may not contain extraneous
	UIDs or the symbol "*".		UIDs or the symbol "*".
	Note: the UID set form of the APPENDUID response code MUST		Note: the UID set form of the APPENDUID response code MUST
	NOT be used if only a single message was appended. In		NOT be used if only a single message was appended. In
	particular, a server MUST NOT send a range such as 123:123.		particular, a server MUST NOT send a range such as 123:123.
			This is because a client which does not support [MULTIAPPEND]
			expects only a single UID and not a UID set.
	UIDs are assigned strictly ascending in the mailbox (refer to		UIDs are assigned strictly ascending in the mailbox (refer to
	[IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in		[IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in
	particular, note that a range of 12:10 is exactly equivalent to		particular, note that a range of 12:10 is exactly equivalent to
	10:12 and refers to the sequence 10,11,12.		10:12 and refers to the sequence 10,11,12.
	This response code is returned in a tagged OK response to the		This response code is returned in a tagged OK response to the
	APPEND command.		APPEND command.
	COPYUID		COPYUID
	Followed by the UIDVALIDITY of the destination mailbox, a UID		Followed by the UIDVALIDITY of the destination mailbox, a UID
	set containing the UIDs of the message(s) in the source mailbox		set containing the UIDs of the message(s) in the source mailbox
	which were copied to the destination mailbox, and a UID set		which were copied to the destination mailbox, and a UID set
	containing the UIDs assigned to the copied message(s) in the		containing the UIDs assigned to the copied message(s) in the
	destination mailbox, indicates that the message(s) have been		destination mailbox, indicates that the message(s) have been
	copied to the destination mailbox with the stated UID(s).		copied to the destination mailbox with the stated UID(s).
	The source UID set is in the order the message(s) were copied; the		The source UID set is in the order the message(s) were copied; the
	destination UID set corresponds to the source UID set and is in		destination UID set corresponds to the source UID set and is in
	the same order. Neither of the UID sets may contain extraneous		the same order. Neither of the UID sets may contain extraneous
	UIDs or the symbol "*".		UIDs or the symbol "*".
	UIDs are assigned strictly ascending in the mailbox (refer to		UIDs are assigned strictly ascending in the mailbox (refer to
	[IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in		[IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in
	particular, note that a range of 12:10 is exactly equivalent to		particular, note that a range of 12:10 is exactly equivalent to
	10:12 and refers to the sequence 10,11,12.		10:12 and refers to the sequence 10,11,12.
	This response code is returned in a tagged OK response to the		This response code is returned in a tagged OK response to the
	COPY command.		COPY command.
	UIDNOTSTICKY		UIDNOTSTICKY
	The selected mailbox is supported by a mail store which does not		The selected mailbox is supported by a mail store which does not
	support persistent UIDs; that is, UIDVALIDITY will be different		support persistent UIDs; that is, UIDVALIDITY will be different
	each time the mailbox is selected. Consequently, APPEND or COPY		each time the mailbox is selected. Consequently, APPEND or COPY
	to this mailbox will not return an APPENDUID or COPYUID response		to this mailbox will not return an APPENDUID or COPYUID response
	code.		code.
	This response code is returned in an untagged NO response to the		This response code is returned in an untagged NO response to the
	SELECT command.		SELECT command.
	Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.		Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
	This facility exists to support legacy mail stores in which		This facility exists to support legacy mail stores in which
	it is technically infeasible to support persistant UIDs.		it is technically infeasible to support persistant UIDs.
	This should be avoided when designing new mail stores.		This should be avoided when designing new mail stores.
	Example: C: A003 APPEND saved-messages (\Seen) {297}		Example: C: A003 APPEND saved-messages (\Seen) {297}
	C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)		C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
	C: From: Fred Foobar <foobar@example.com>		C: From: Fred Foobar <foobar@example.com>
	C: Subject: afternoon meeting		C: Subject: afternoon meeting
	C: To: mooch@example.com		C: To: mooch@example.com
	C: Message-Id: <B27397-0100000@example.com>		C: Message-Id: <B27397-0100000@example.com>
	C: MIME-Version: 1.0		C: MIME-Version: 1.0
	C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII		C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
	C:		C:
	C: Hello Joe, do you think we can meet at 3:30 tomorrow?		C: Hello Joe, do you think we can meet at 3:30 tomorrow?
	C:		C:
	S: A003 OK [APPENDUID 38505 3955] APPEND completed		S: A003 OK [APPENDUID 38505 3955] APPEND completed
	C: A004 COPY 2:4 meeting		C: A004 COPY 2:4 meeting
	S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done		S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
	C: A005 UID COPY 305:310 meeting		C: A005 UID COPY 305:310 meeting
	S: A005 OK No matching messages, so nothing copied		S: A005 OK No matching messages, so nothing copied
	C: A006 COPY 2 funny		C: A006 COPY 2 funny
	S: A006 OK Done		S: A006 OK Done
	C: A007 SELECT funny		C: A007 SELECT funny
	S: * 1 EXISTS		S: * 1 EXISTS
	S: * 1 RECENT		S: * 1 RECENT
	S: * OK [UNSEEN 1] Message 1 is first unseen		S: * OK [UNSEEN 1] Message 1 is first unseen
	S: * OK [UIDVALIDITY 3857529045] Validity session-only		S: * OK [UIDVALIDITY 3857529045] Validity session-only
	S: * OK [UIDNEXT 2] Predicted next UID		S: * OK [UIDNEXT 2] Predicted next UID
	S: * NO [UIDNOTSTICKY] Non-persistent UIDs		S: * NO [UIDNOTSTICKY] Non-persistent UIDs
	S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)		S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
	S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited		S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
	S: A007 OK [READ-WRITE] SELECT completed		S: A007 OK [READ-WRITE] SELECT completed
	In this example, A003 and A004 demonstrate successful appending and		In this example, A003 and A004 demonstrate successful appending and
	copying to a mailbox which returns the UIDs assigned to the messages.		copying to a mailbox which returns the UIDs assigned to the messages.
	A005 is an example in which no messages were copied; this is because		A005 is an example in which no messages were copied; this is because
	in A003 we see that message 2 had UID 304 and message 3 had UID 319;		in A003 we see that message 2 had UID 304 and message 3 had UID 319;
	therefore UIDs 305 through 310 do not exist (refer to section 2.3.1.1		therefore UIDs 305 through 310 do not exist (refer to section 2.3.1.1
	of [IMAP] for further explanation). A006 is an example of a message		of [IMAP] for further explanation). A006 is an example of a message
	being copied that did not return a COPYUID; and as expected A007		being copied that did not return a COPYUID; and as expected A007
	shows that the mail store containing that mailbox does not support		shows that the mail store containing that mailbox does not support
	persistent UIDs.		persistent UIDs.
	5. Formal Syntax		5. Formal Syntax
	Formal syntax is defined using ABNF [ABNF], extending the ABNF rules		Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
	defined in [IMAP4]. The IMAP4 ABNF should be imported first before		defined in [IMAP4]. The IMAP4 ABNF should be imported first before
	attempting to validate these rules.		attempting to validate these rules.
	append-uid = uniqueid		append-uid = uniqueid
	capability =/ "UIDPLUS"		capability =/ "UIDPLUS"
	command-select =/ uid-expunge		command-select =/ uid-expunge
	resp-code-apnd = "APPENDUID" SP nz-number SP append-uid		resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
	resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set		resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set
	resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"		resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
	; incorporated before the expansion rule of		; incorporated before the expansion rule of
	; atom [SP 1*<any TEXT-CHAR except "]">]		; atom [SP 1*<any TEXT-CHAR except "]">]
	; which appears in [IMAP]		; which appears in [IMAP]
	uid-expunge = "UID" SP "EXPUNGE" SP sequence-set		uid-expunge = "UID" SP "EXPUNGE" SP sequence-set
	uid-set = (uniqueid / uid-range) *("," uid-set)		uid-set = (uniqueid / uid-range) *("," uid-set)
	uid-range = (uniqueid ":" uniqueid)		uid-range = (uniqueid ":" uniqueid)
	; two non-equal uniqueid values and all		; two uniqueid values and all values
	; values between these two regards of order.		; between these two regards of order.
	; Example: 2:4 and 4:2 are equivalent.		; Example: 2:4 and 4:2 are equivalent.
	; These values MUST NOT be equal; e.g. 2:2
	; is not permitted.
	Servers which support [MULTIAPPEND] will have the following extension		Servers which support [MULTIAPPEND] will have the following extension
	to the above rules:		to the above rules:
	append-uid =/ uid-set		append-uid =/ uid-set
	; only if multiple messages appended		; only permitted if client uses [MULTIAPPEND]
			; to append multiple messages.
	Security Considerations		Security Considerations
	The COPYUID and APPENDUID response codes return information about the		The COPYUID and APPENDUID response codes return information about the
	mailbox. These response codes SHOULD NOT be issused if the client		mailbox. These response codes SHOULD NOT be issused if the client
	does not have access to SELECT or EXAMINE the mailbox.		does not have access to SELECT or EXAMINE the mailbox.
	IANA Considerations		IANA Considerations
	This document constitutes registration of the UIDPLUS capability in		This document constitutes registration of the UIDPLUS capability in
	the imap4-capabilities registry, replacing RFC 2359.		the imap4-capabilities registry, replacing RFC 2359.
	Normative References		Normative References
	[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[IMAP] Crispin, M., "Internet Message Access Protocol -		[IMAP] Crispin, M., "Internet Message Access Protocol -
	Version 4rev1", RFC 3501, March 2003.		Version 4rev1", RFC 3501, March 2003.
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -		[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
	MULTIAPPEND Extension", RFC 3502, March 2003.		MULTIAPPEND Extension", RFC 3502, March 2003.
	[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April		[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
	2001.		2001.
	Informative References		Informative References
	[RFC-2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June		[RFC-2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
	1988.		1988.
	Acknowledgements		Acknowledgements
	This document obsoletes [RFC-2359]. However, it is based upon that		This document obsoletes [RFC-2359]. However, it is based upon that
	document, and takes substantial text from it.		document, and takes substantial text from it.
	Author's Address		Author's Address
	Mark R. Crispin		Mark R. Crispin
	Networks and Distributed Computing		Networks and Distributed Computing
	University of Washington		University of Washington
	4545 15th Avenue NE		4545 15th Avenue NE
	Seattle, WA 98105-4527		Seattle, WA 98105-4527
	Phone: (206) 543-5762		Phone: (206) 543-5762
	EMail: MRC@CAC.Washington.EDU		EMail: MRC@CAC.Washington.EDU
	IPR Disclosure Acknowledgement		IPR Disclosure Acknowledgement
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances 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		licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification can		proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided		This document and the information contained herein are provided
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.		PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		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		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 78 change blocks.
	280 lines changed or deleted		281 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/