< draft-ietf-repute-query-http-05.txt		draft-ietf-repute-query-http-06.txt >
	REPUTE Working Group N. Borenstein		REPUTE Working Group N. Borenstein
	Internet-Draft Mimecast		Internet-Draft Mimecast
	Intended status: Standards Track M. Kucherawy		Intended status: Standards Track M. Kucherawy
	Expires: November 6, 2013 May 5, 2013		Expires: November 17, 2013 May 16, 2013
	A Reputation Query Protocol		A Reputation Query Protocol
	draft-ietf-repute-query-http-05		draft-ietf-repute-query-http-06
	Abstract		Abstract
	This document defines a mechanism to conduct queries for reputation		This document defines a mechanism to conduct queries for reputation
	information over the Hypertext Transfer Protocol using JSON as the		information over the Hypertext Transfer Protocol using JSON as the
	payload meta-format.		payload meta-format.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on November 6, 2013.		This Internet-Draft will expire on November 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Definitions . . . . . . . . . . . . . . . . . . 3		2. Terminology and Definitions . . . . . . . . . . . . . . . . . . 3
	2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Other Definitions . . . . . . . . . . . . . . . . . . . . . 3		2.2. Other Definitions . . . . . . . . . . . . . . . . . . . . . 3
	3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. URI Template . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. URI Template . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.5. Protocol Support . . . . . . . . . . . . . . . . . . . . . 6		3.5. Protocol Support . . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
	Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 8		Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 31 ¶
	2.2. Other Definitions		2.2. Other Definitions
	Other terms of importance in this document are defined in		Other terms of importance in this document are defined in
	[I-D.REPUTE-MODEL] and [I-D.REPUTE-MEDIA-TYPE].		[I-D.REPUTE-MODEL] and [I-D.REPUTE-MEDIA-TYPE].
	3. Description		3. Description
	3.1. Overview		3.1. Overview
	A reputation query made via [HTTP] encodes the question being asked
	in an HTTP GET method.
	The components to the question being asked comprise the following:		The components to the question being asked comprise the following:
	o The subject of the query;		o The subject of the query;
	o The name of the host, or the IP address, at which the reputation		o The name of the host, or the IP address, at which the reputation
	service is available;		service is available;
	o The name of the reputation application, i.e., the context within		o The name of the reputation application, i.e., the context within
	which the query is being made;		which the subject is being evaluated;
	o Optionally, name(s) of the specific reputation assertions or		o Optionally, name(s) of the specific reputation assertions or
	attributies that are being requested.		attributies that are being requested.
	The name of the application, if given, MUST be one registered with		The name of the application, if given, MUST be one registered with
	IANA in the Reputation Applications Registry. A server receiving a		IANA in the Reputation Applications Registry, which is defined in
	query about an unregistered application or one it does not explicitly		[I-D.REPUTE-MEDIA-TYPE]. A server receiving a query about an
	support MUST return a 404 error code.		unregistered application or one it does not explicitly support (e.g.,
			by virtue of private agreements or experimental extensions) MUST
			return a 404 error code.
			A reputation query made via [HTTP] encodes the question being asked
			in an HTTP GET method.
	3.2. Syntax		3.2. Syntax
	The syntax for the [URI] portion of the query is constructed using a		The syntax for the [URI] of the query is constructed using a template
	template as per [URI-TEMPLATE]. (See Section 3.3.) The following		as per [URI-TEMPLATE]. (See Section 3.3.) The following variables
	variables MUST be available during template expansion:		MUST be available during template expansion:
	application: The name of the application reputation in whose context		application: The name of the application reputation in whose context
	the request is being made.		the request is being made.
	scheme: The transport scheme the client will be using for the query.		scheme: The transport scheme the client will be using for the query.
	service: The hostname or IP address being queried.		service: The hostname or IP address to which the query is being
			sent.
	subject: The subject of the query.		subject: The subject of the query.
	Which scheme(s) can be used depends on how the reputation service		Which scheme(s) can be used depends on how the reputation service
	provider offers its services. Thus, the template could include a		provider offers its services. Thus, the template could include a
	specific scheme as a fixed string in the template, or it might offer		specific scheme as a fixed string in the template, or it might offer
	it as a variable in the template. If it is a variable, it is up to		it as a variable in the template. If it is a variable, it is up to
	the client and server to negotiate out-of-band which schemes are		the client and server to negotiate out-of-band which schemes are
	supported for client queries. Implementers need to be aware that the		supported for client queries. Implementers need to be aware that the
	template could include a fixed scheme not supported by the client.		template could include a fixed scheme not supported by the client.
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 43 ¶
	forcing clients to use the "http" URI scheme only:		forcing clients to use the "http" URI scheme only:
	http://{service}/repute.php{?subject,application,assertion}		http://{service}/repute.php{?subject,application,assertion}
	However, this template allows the client to select the scheme to be		However, this template allows the client to select the scheme to be
	used if, for example, the service is also available over the "https"		used if, for example, the service is also available over the "https"
	URI scheme:		URI scheme:
	{scheme}://{service}/repute.php{?subject,application,assertion}		{scheme}://{service}/repute.php{?subject,application,assertion}
	The following variables are OPTIONAL, but might be required by the		The following variables are OPTIONAL to this base specification, but
	template presented for a specific service:		might be required by the template presented for a specific service:
	assertion: A list of one or more specific assertions of interest to		assertion: A list of one or more specific assertions of interest to
	the client. If absent, the server MUST infer that all available		the client. If absent, the server MUST infer that all available
	assertion information is being requested.		assertion information is being requested.
	Every application space has a set of assertions applicable to its own		Every application space has a set of assertions applicable to its own
	context. [I-D.REPUTE-MEDIA-TYPE] defines a single assertion assumed		context. [I-D.REPUTE-MEDIA-TYPE] defines a single assertion assumed
	to exist in any application that does not define its own assertion		to exist in any application that does not define its own assertion
	set.		set.
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	Nathaniel Borenstein		Nathaniel Borenstein
	Mimecast		Mimecast
	203 Crescent St., Suite 303		203 Crescent St., Suite 303
	Waltham, MA 02453		Waltham, MA 02453
	USA		USA
	Phone: +1 781 996 5340		Phone: +1 781 996 5340
	Email: nsb@guppylake.com		Email: nsb@guppylake.com
	Murray S. Kucherawy		Murray S. Kucherawy
	2063 42nd Avenue		270 Upland Drive
	San Francisco, CA 94116		San Francisco, CA 94127
	USA		USA
	Email: superuser@gmail.com		Email: superuser@gmail.com
End of changes. 11 change blocks.
	19 lines changed or deleted		22 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/