< draft-showalter-imap-id-03.txt		draft-showalter-imap-id-04.txt >
	Network Working Group T. Showalter		Network Working Group T. Showalter
	Internet Draft: IMAP ID Extension Mirapoint, Inc.		Internet Draft: IMAP ID Extension Mirapoint, Inc.
	Document: draft-showalter-imap-id-03.txt August 3, 1999		Document: draft-showalter-imap-id-04.txt July 13, 2000
	IMAP4 ID extension		IMAP4 ID extension
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.		all provisions of Section 10 of RFC 2026.
	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
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	from users, as it is frequently difficult to know what client or		from users, as it is frequently difficult to know what client or
	server is in use.		server is in use.
	Additionally, some sites may wish to assemble usage statistics based		Additionally, some sites may wish to assemble usage statistics based
	on what clients are used, but in an an environment where users are		on what clients are used, but in an an environment where users are
	permitted to obtain and maintain their own clients this is difficult		permitted to obtain and maintain their own clients this is difficult
	to accomplish.		to accomplish.
	The ID command provides a facility to advertise information on what		The ID command provides a facility to advertise information on what
	Internet DRAFT IMAP ID August 3, 1999		Internet DRAFT IMAP ID July 13, 2000
	programs are being used along with contact information (should bugs		programs are being used along with contact information (should bugs
	ever occur).		ever occur).
	2. Conventions Used in this Document		2. Conventions Used in this Document
			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.
	The conventions used in this document are the same as specified in		The conventions used in this document are the same as specified in
	[IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the		[IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the
	client and server respectively. Line breaks have been inserted for		client and server respectively. Line breaks have been inserted for
	readability.		readability.
	3. Specification		3. Specification
	The sole purpose of the ID extension is to enable clients and servers		The sole purpose of the ID extension is to enable clients and servers
	to exchange information on their implementations for the purposes of		to exchange information on their implementations for the purposes of
	statistical analysis and problem determination.		statistical analysis and problem determination.
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 40 ¶
	included in the list of capabilities returned by the CAPABILITY		included in the list of capabilities returned by the CAPABILITY
	command.		command.
	Implementations MUST NOT make operational changes based on the data		Implementations MUST NOT make operational changes based on the data
	sent as part of the ID command or response. The ID command is for		sent as part of the ID command or response. The ID command is for
	human consumption only, and is not to be used in improving the		human consumption only, and is not to be used in improving the
	performance of clients or servers.		performance of clients or servers.
	This includes, but is not limited to, the following:		This includes, but is not limited to, the following:
	Servers MUST NOT attempt to work around a client bugs by using		Servers MUST NOT attempt to work around client bugs by using
	information from the ID command. Clients MUST NOT attempt to work		information from the ID command. Clients MUST NOT attempt to work
	around server bugs based on the ID response.		around server bugs based on the ID response.
	Servers MUST NOT provide features to a client or otherwise		Servers MUST NOT provide features to a client or otherwise
	optimize for a particular client by using information from the ID		optimize for a particular client by using information from the ID
	command. Clients MUST NOT provide features to a server or		command. Clients MUST NOT provide features to a server or
	otherwise optimize for a particular server based on the ID		otherwise optimize for a particular server based on the ID
	response.		response.
	Servers MUST NOT deny access to or refuse service for a client		Servers MUST NOT deny access to or refuse service for a client
	based on information from the ID command. Clients MUST NOT refuse		based on information from the ID command. Clients MUST NOT refuse
	to operate or limit their operation with a server based on the ID		to operate or limit their operation with a server based on the ID
	response.		response.
			Internet DRAFT IMAP ID July 13, 2000
	Rationale: It is imperative that this extension not supplant IMAP's		Rationale: It is imperative that this extension not supplant IMAP's
	CAPABILITY mechanism with a ad-hoc approach where implementations		CAPABILITY mechanism with a ad-hoc approach where implementations
	guess each other's features based on who they claim to be.		guess each other's features based on who they claim to be.
	Internet DRAFT IMAP ID August 3, 1999
	Implementations MUST NOT send false information in an ID command.		Implementations MUST NOT send false information in an ID command.
	Implementations MAY send less information than they have available or		Implementations MAY send less information than they have available or
	no information at all. Such behavior may be useful to preserve user		no information at all. Such behavior may be useful to preserve user
	privacy. See Security Considerations, section 6.		privacy. See Security Considerations, section 8.
	3.1. ID Command		3.1. ID Command
	Arguments: client parameter list or NIL		Arguments: client parameter list or NIL
	Responses: OPTIONAL untagged response: ID		Responses: OPTIONAL untagged response: ID
	Result: OK identification information accepted		Result: OK identification information accepted
	BAD command unknown or arguments invalid		BAD command unknown or arguments invalid
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 42 ¶
	Fields are permitted to be any IMAP4 string, and values are permitted		Fields are permitted to be any IMAP4 string, and values are permitted
	to be any IMAP4 string or NIL. A value of NIL indicates that the		to be any IMAP4 string or NIL. A value of NIL indicates that the
	client can not or will not specify this information. The client may		client can not or will not specify this information. The client may
	also send NIL instead of the list, indicating that it wants to send		also send NIL instead of the list, indicating that it wants to send
	no information, but would still accept a server response.		no information, but would still accept a server response.
	The available fields are defined in section 3.3.		The available fields are defined in section 3.3.
	Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor"		Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
	"Pink Floyd Music Limited")		"Pink Floyd Music Limited")
			S: * ID NIL
	S: a023 OK ID completed		S: a023 OK ID completed
			Internet DRAFT IMAP ID July 13, 2000
	3.2. ID Response		3.2. ID Response
	Contents: server parameter list		Contents: server parameter list
	In response to an ID command issued by the client, the server MAY		In response to an ID command issued by the client, the server replies
	reply with a tagged response containing information on its		with a tagged response containing information on its implementation.
	implementation. The format is the same as the client list.		The format is the same as the client list.
	Example: C: a023 ID NIL		Example: C: a042 ID NIL
	S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"		S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
	"os-version" "5.5" "email"		"os-version" "5.5" "support-url"
	"cyrus-bugs+@andrew.cmu.edu")		"mailto:cyrus-bugs+@andrew.cmu.edu")
	S: a023 OK ID command completed		S: a042 OK ID command completed
	A server MUST send a tagged ID response to an ID command. However, a		A server MUST send a tagged ID response to an ID command. However, a
			server MAY send NIL in place of the list.
	Internet DRAFT IMAP ID August 3, 1999
	server may send NIL in place of the list.
	3.3. Defined Field Values		3.3. Defined Field Values
	Any string may be sent as a field, but the following are defined to		Any string may be sent as a field, but the following are defined to
	describe certain values that might be sent. Implementations are free		describe certain values that might be sent. Implementations are free
	to send none, any, or all of these. Strings are not case-sensitive.		to send none, any, or all of these. Strings are not case-sensitive.
	Field strings MUST NOT be longer than 30 octets. Value strings MUST		Field strings MUST NOT be longer than 30 octets. Value strings MUST
	NOT be longer than 1024 octets. Implementations MUST NOT send more		NOT be longer than 1024 octets. Implementations MUST NOT send more
	than 30 field-value pairs.		than 30 field-value pairs.
	name Name of the program		name Name of the program
	version Version number of the program		version Version number of the program
	os Name of the operating system		os Name of the operating system
	os-version Version of the operating system		os-version Version of the operating system
	vendor Vendor of the client/server		vendor Vendor of the client/server
	support-url URL to contact for support		support-url URL to contact for support
	address Postal address of contact/vendor		address Postal address of contact/vendor
	date Date program was released; should be in a		date Date program was released, specified as a date-time
	human-readable form		in IMAP4rev1
	command Command used to start the program		command Command used to start the program
	arguments Arguments supplied on the command line, if any		arguments Arguments supplied on the command line, if any
	if any		if any
	environment Description of environment, i.e., UNIX environment		environment Description of environment, i.e., UNIX environment
	variables or Windows registry settings		variables or Windows registry settings
	Implementations MUST NOT use contact information to submit automatic		Implementations MUST NOT use contact information to submit automatic
	bug reports. Implementations may include information from an ID		bug reports. Implementations may include information from an ID
	response in a report automatically prepared, but are prohibited from		response in a report automatically prepared, but are prohibited from
	sending the report without user authorization.		sending the report without user authorization.
	It is preferable to find the name and version of the underlying		It is preferable to find the name and version of the underlying
	operating system at runtime in cases where this is possible.		operating system at runtime in cases where this is possible.
			Internet DRAFT IMAP ID July 13, 2000
	Information sent via an ID response may violate user privacy. See		Information sent via an ID response may violate user privacy. See
	Security Considerations, section 6.		Security Considerations, section 8.
	Implementations MUST NOT send the same field name more than once.		Implementations MUST NOT send the same field name more than once.
	Internet DRAFT IMAP ID August 3, 1999
	4. Formal Syntax		4. Formal Syntax
	This syntax is intended to augment the grammar specified in		This syntax is intended to augment the grammar specified in
	[IMAP4rev1] in order to provide for the ID command. This		[IMAP4rev1] in order to provide for the ID command. This
	specification uses the augmented Backus-Naur Form (BNF) notation as		specification uses the augmented Backus-Naur Form (BNF) notation as
	used in [IMAP4rev1].		used in [IMAP4rev1].
	command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id		command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
	;; adds id command to command_any in [IMAP4rev1]		;; adds id command to command_any in [IMAP4rev1]
	id ::= "ID" SPACE id_params_list		id ::= "ID" SPACE id_params_list
	id_response ::= "ID" SPACE id_params_list		id_response ::= "ID" SPACE id_params_list
	id_params_list ::= "(" #(string SPACE nstring) ")" / nil		id_params_list ::= "(" #(string SPACE nstring) ")" / nil
	;; list of field value pairs		;; list of field value pairs
	response_data ::= "*" (resp_cond_state / resp_cond_bye /		response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
	mailbox_data / message_data / capability_data / id_response)		mailbox_data / message_data / capability_data / id_response)
	5. References		5. Use of the ID extension with firewalls and other intermediaries
			There exist proxies, firewalls, and other intermediary systems that
			can intercept an IMAP session and make changes to the data exchanged
			in the session. Such intermediaries are not anticipated by the IMAP4
			protocol design and are not within the scope of the IMAP4 standard.
			However, in order for the ID command to be useful in the presence of
			such intermediaries, those intermediaries need to take special note
			of the ID command and response. In particular, if an intermediary
			changes any part of the IMAP session it must also change the ID
			command to advertise its presence.
			6. References
	[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version		[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
	4rev1", RFC 2060, University of Washington, October, 1996.		4rev1", RFC 2060, University of Washington, October, 1996.
	[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet		[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
	Text Messages", STD 11, RFC 822.		Text Messages", STD 11, RFC 822.
	6. Security Considerations		Internet DRAFT IMAP ID July 13, 2000
			7. Firewall Considerations
			A firewall MAY act to block transmission of specific information
			fields in the ID command and response that it believes reveal
			information that could expose a security vulnerability. However, a
			firewall SHOULD NOT disable the extension, when present, entirely,
			and SHOULD NOT unconditionally remove either the client or server
			list.
			Finally, it should be noted that a firewall, when handling a
			capability response, MUST NOT allow the names of extensions to be
			returned to the client that it has no knowledge of.
			8. Security Considerations
	This extension has the danger of violating the privacy of users if		This extension has the danger of violating the privacy of users if
	misused. Clients and servers should notify users that they implement		misused. Clients and servers should notify users that they implement
	and enable the ID command.		and enable the ID command.
	It is highly desirable that implementations provide a method of		It is highly desirable that implementations provide a method of
	disabling ID support, perhaps by not sending ID at all, or by sending		disabling ID support, perhaps by not sending ID at all, or by sending
	NIL as the argument to the ID command or response.		NIL as the argument to the ID command or response.
	Implementors must exercise extreme care in adding fields sent as part		Implementors must exercise extreme care in adding fields sent as part
	of an ID command or response. Some fields, including a processor ID		of an ID command or response. Some fields, including a processor ID
	number, Ethernet address, or other unique (or mostly unique)		number, Ethernet address, or other unique (or mostly unique)
	identifier allow tracking of users in ways that violate user privacy		identifier allow tracking of users in ways that violate user privacy
	expectations.		expectations.
	Having implementation information of a given client or server may		Having implementation information of a given client or server may
	make it easier for an attacker to gain unauthorized access due to		make it easier for an attacker to gain unauthorized access due to
	security holes.		security holes.
	Internet DRAFT IMAP ID August 3, 1999		Since this command includes arbitrary data and does not require the
			user to authenticate, server implementations are cautioned to guard
			against an attacker sending arbitrary garbage data in order to fill
			up the ID log. In particular, if a server naively logs each ID
			command to disk without inspecting it, an attacker can simply fire up
			thousands of connections and send a few kilobytes of random data.
			Servers have to guard against this. Methods include truncating
			abnormally large responses; collating responses by storing only a
			single copy, then keeping a counter of the number of times that
			response has been seen; keeping only particularly interesting parts
			of responses; and only logging responses of users who actually log
			in.
	7. Author's Address		Security is affected by firewalls which modify the IMAP protocol
			stream; see section 7, Firewall Considerations, for more information.
			Internet DRAFT IMAP ID July 13, 2000
			9. Author's Address
	Tim Showalter		Tim Showalter
	Mirapoint, Inc.		Mirapoint, Inc.
	Two Results Way, Suite 100		Two Results Way, Suite 100
	Cupertino, CA 95014		Cupertino, CA 95014
	tjs@mirapoint.com		tjs@mirapoint.com
	8. Full Copyright Statement		10. Full Copyright Statement
	Copyright (C) The Internet Society 1999. All Rights Reserved.		Copyright (C) The Internet Society 1999. All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
End of changes. 24 change blocks.
	28 lines changed or deleted		76 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/