< draft-ietf-repute-query-http-07.txt		draft-ietf-repute-query-http-08.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: December 8, 2013 June 6, 2013		Expires: January 4, 2014 July 3, 2013
	A Reputation Query Protocol		A Reputation Query Protocol
	draft-ietf-repute-query-http-07		draft-ietf-repute-query-http-08
	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 December 8, 2013.		This Internet-Draft will expire on January 4, 2014.
	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. URI Template . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. URI Template . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.5. Protocol Support . . . . . . . . . . . . . . . . . . . . . 6		3.5. Protocol Support . . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . . 8		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
	1. Introduction		1. Introduction
	This document defines a method to query a reputation data service for		This document defines a method to query a reputation data service for
	information about an entity, using the HyperText Transfer Protocol		information about an entity, using the HyperText Transfer Protocol
	(HTTP) as the transport mechanism and JSON as the payload meta-		(HTTP) as the transport mechanism and JSON as the payload meta-
	format.		format.
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	Clients SHOULD NOT repeat the query prior to the timestamp in the		Clients SHOULD NOT repeat the query prior to the timestamp in the
	Expires field, or wait no less than one day if the Expires field is		Expires field, or wait no less than one day if the Expires field is
	not present.		not present.
	The template file might contain more than one template. Such a file		The template file might contain more than one template. Such a file
	MUST have each template separated by a newline (ASCII 0x0D)		MUST have each template separated by a newline (ASCII 0x0D)
	character.		character.
	Each template in the file is expanded using the variables that are		Each template in the file is expanded using the variables that are
	the parameters to the query. The client then selects any expanded		the parameters to the query. These parameters are either the subject
	template it is able to use (i.e., using a scheme the client		about which reputation information is sought (or details associated
	supports), and then uses the expanded template as the target for the		with it), or other parameters that are established out-of-band with
	query itself. This allows for discovery of alternatives to HTTP that		the reputation service; they are not established by any automated
	the client might be able to use.		discovery described here. The client then attempts to query each
			expanded template that uses a scheme it is cable of querying, in the
			order presented in the file, until finds one to which it can
			establish a usable connection and issue the query.
	For example, given the following template:		For example, given the following template:
	{scheme}://{service}/{application}/{subject}/{assertion}		http://{service}/{application}/{subject}/{assertion}
	A query about the use of the domain "example.org" in the "email-id"		A query about the use of the domain "example.org" in the "email-id"
	application context to a service run at "example.com", where that		application context to a service run at "example.com", where that
	application declares a required "subject" parameter, requesting the		application declares a required "subject" parameter, requesting the
	"SPAM" reputation assertion, using HTTP to conduct the query with no		"SPAM" reputation assertion, would be formed as follows:
	specific client authentication information, would be formed as
	follows:
	http://example.com/email-id/example.org/spam		http://example.com/email-id/example.org/spam
	3.3. Syntax		3.3. Syntax
	The syntax for the [URI] of the query is constructed using a template		The syntax for the [URI] of the query is constructed using a template
	as per [URI-TEMPLATE]. (See Section 3.2.) Clients MUST have the		as per [URI-TEMPLATE]. (See Section 3.2.) Clients MUST provide the
	following available for template expansion:		following values in the expansion of the template:
	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.
	service: The hostname or IP address to which the query is being		service: The hostname or IP address to which the query is being
	sent.		sent. This MUST be the same as the host to which the template
			query was issued.
	subject: The subject of the query.
	Which scheme(s) can be used depends on how the reputation service
	provider offers its services. Thus, the template could include a
	specific scheme as a fixed string in the template, or it might offer
	it as a variable in the template. Note that a template could specify
	a scheme the client is not equipped to use.
	For example, the following query template includes a fixed scheme,
	forcing clients to use the "http" URI scheme only:
	http://{service}/repute.php{?subject,application,assertion}
	However, this template allows the client to select the scheme to be
	used if, for example, the service is also available over the "https"
	URI scheme:
	{scheme}://{service}/repute.php{?subject,application,assertion}		subject: The subject of the query, extracted from some content to be
			evaluated.
	The following variable is OPTIONAL to this base specification, but		The following variable can also be provided. It is not mandatory in
	might be required by the template presented for a specific service:		this model, but a specific application (defined in its own extension
			document) might declare it mandatory in a specific context:
	assertion: A list of one or more specific assertions of interest to		assertion: The name of the specific assertion of interest to the
	the client. If absent, the client is indicating that it requests		client. If absent, the client is indicating that it requests all
	all available assertion information.		available assertion information.
	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.
	Reputation applications can extend the set of optional or required		Reputation applications can extend the set of optional or required
	query parameters as part of their IANA registration actions. The set		query parameters as part of their IANA registration actions. The set
	enumerated above establishes the base set common to all of them.		enumerated above establishes the base set common to all of them.
	Further, additional required or optional extension query parameters		Further, additional required or optional extension query parameters
	might be defined by specific reputation service providers, though		might be defined by specific reputation service providers, though
	these are private arrangements between client and server and will not		these are private arrangements between client and server and will not
	be registered with IANA.		be registered with IANA.
	Authentication between reputation client and server is outside the		Authentication between reputation client and server is outside the
	scope of this specification. It could be provided through a variety		scope of this specification. It could be provided through a variety
	of available transport-based or object-based mechanisms, including a		of available transport-based or object-based mechanisms, including a
	later extension of this specification.		later extension of this specification.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 10 ¶
	The response is expected to be contained in a media type designed to		The response is expected to be contained in a media type designed to
	deliver reputons. An media type designed for this purpose,		deliver reputons. An media type designed for this purpose,
	"application/reputon+json", is defined in [I-D.REPUTE-MEDIA-TYPE].		"application/reputon+json", is defined in [I-D.REPUTE-MEDIA-TYPE].
	3.5. Protocol Support		3.5. Protocol Support
	A client has to implement HTTP in order to retrieve the query		A client has to implement HTTP in order to retrieve the query
	template as described in Section 3.2. Accordingly, a server can		template as described in Section 3.2. Accordingly, a server can
	assume the client will be able to handle a URI template that produces		assume the client will be able to handle a URI template that produces
	a URI for the query using the "http" scheme. If the template can		a URI for the query using the "http" scheme. The template could
	yield a query string that uses some other URI scheme, there will need		yield a query string that uses some other URI scheme, in which case
	to be some out-of-band negotiation of which scheme(s) are supported		the client could try that URI as well if it supports issuing queries
	by the service, and appropriate protocol support in the client.		with that scheme.
	A server SHOULD include support for providing service over HTTP, and		A server SHOULD include support for providing service over HTTP, and
	publish templates indicating support for this, as a baseline for		publish templates indicating support for this, as a baseline for
	interoperability with arbitrary clients.		interoperability with arbitrary clients.
	4. IANA Considerations		4. IANA Considerations
	This document registers the "repute-template" well-known URI in the		This document registers the "repute-template" well-known URI in the
	Well-Known URI registry as defined by [WELL-KNOWN-URI], as follows:		Well-Known URI registry as defined by [WELL-KNOWN-URI], as follows:
End of changes. 17 change blocks.
	48 lines changed or deleted		32 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/