< draft-ietf-repute-query-http-04.txt		draft-ietf-repute-query-http-05.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: May 17, 2013 November 13, 2012		Expires: November 6, 2013 May 5, 2013
	Reputation Data Interchange using HTTP and JSON		A Reputation Query Protocol
	draft-ietf-repute-query-http-04		draft-ietf-repute-query-http-05
	Abstract		Abstract
	This document defines a mechanism to conduct queries for reputation		This document defines a mechanism to conduct queries for reputation
	information using the Hypertext Transfer Protocol.		information over the Hypertext Transfer Protocol using JSON as the
			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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 17, 2013.		This Internet-Draft will expire on November 6, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		3.3. URI Template . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.5. Protocol Support . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . . 7
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
			Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 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 format.		(HTTP) as the transport mechanism and JSON as the payload meta-
			format.
	2. Terminology and Definitions		2. Terminology and Definitions
	This section defines terms used in the rest of the document.		This section defines terms used in the rest of the document.
	2.1. Key Words		2.1. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [KEYWORDS].		document are to be interpreted as described in [KEYWORDS].
	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. Query		3.1. Overview
	A reputation query made via [HTTP] encodes the question being asked		A reputation query made via [HTTP] encodes the question being asked
	in the GET instruction of the protocol.		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 query is being made;
	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. A server receiving a query about an unregistered application		IANA in the Reputation Applications Registry. A server receiving a
	or one it does not explicitly support MUST return a 404 error code.		query about an unregistered application or one it does not explicitly
			support MUST return a 404 error code.
			3.2. Syntax
	The syntax for the [URI] portion of the query is constructed using a		The syntax for the [URI] portion of the query is constructed using a
	template as per [URI-TEMPLATE]. The following variables MUST be		template as per [URI-TEMPLATE]. (See Section 3.3.) The following
	available during template expansion:		variables 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 being queried.
	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.
			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}
	The following variables are OPTIONAL, but might be required by the		The following variables are OPTIONAL, but might be required by the
	template presented for a specific service:		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
			context. [I-D.REPUTE-MEDIA-TYPE] defines a single assertion assumed
			to exist in any application that does not define its own assertion
			set.
	Other required or optional query parameters might be defined by		Other required or optional query parameters might be defined by
	documents that register new response sets with IANA. Further, other		documents that register new response sets with IANA. Further, other
	required or optional query parameters might be defined by specific		required or optional query parameters might be defined by specific
	reputation service providers, though these are private arrangements		reputation service providers, though these are private arrangements
	between client and server and will not be registered with IANA.		between client and server and will not be registered with IANA.
	Authentication between reputation client and server MAY be		Authentication between reputation client and server is outside the
	accomplished using query extensions, or MAY rely on the capabilities		scope of this specificatin. It could be provided through a variety
	of the transport associated with the selected URI scheme.		of available transport-based or object-based mechanisms, including a
			later extension of this specification.
			3.3. URI Template
	The template is retrieved by requesting the [WELL-KNOWN-URI] "repute-		The template is retrieved by requesting the [WELL-KNOWN-URI] "repute-
	template" from the host providing reputation service using HTTP. The		template" from the host providing reputation service using HTTP.
	server SHOULD return the template in a text/plain reply. If the		(The registration for this well-known URI is in Section 4.) The
	template cannot be retrieved, the reputation query SHOULD be aborted		server MUST return the template in a reply using the text/plain media
	and/or retried at a later time. The server responding to the		type (see [MIME]), and SHOULD include an Expires field (see Section
	template request SHOULD include an Expires field indicating a		14.21 of [HTTP]) indicating a duration for which the template is to
	duration for which the template should be considered valid by clients		be considered valid by clients and not re-queried.
	and not re-queried. Clients SHOULD adhere to the expiration time
	thus provided or, if none is provided, assume that the template is
	valid for no less than one day and SHOULD NOT repeat the query.
	For example, given the following template:		If the template cannot be retrieved (i.e., any HTTP error is
			returned), the reputation query SHOULD be aborted and/or retried at a
			later time. Clients SHOULD adhere to the expiration time presented
			in an Expires field, if present, or otherwise assume that the
			template is valid for no less than one day and SHOULD NOT repeat the
			query.
			The template is expanded, using the variables that are the parameters
			to the query, and then used as the target for the query itself. For
			example, given the following template:
	{scheme}://{service}/{application}/{subject}/{assertion}		{scheme}://{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, using HTTP to conduct the query with no
	specific client authentication information would be formed as		specific client authentication information, would be formed as
	follows:		follows:
	http://example.com/email-id/example.org/spam		http://example.com/email-id/example.org/spam
	Matching of the attribute name(s) MUST be case-insensitive.		Matching of the attribute name(s) in the template MUST be case-
			insensitive.
	3.2. Response		3.4. Response
	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
			A client has to implement HTTP in order to retrieve the query
			template as described in Section 3.3. Accordingly, a server can
			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
			yield a query string that uses some other URI scheme, there will need
			to be some out-of-band negotiation of which scheme(s) are supported
			by the service, and appropriate protocol support in the client.
	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:
	URI suffix: repute-template		URI suffix: repute-template
	Change controller: IETF		Change controller: IETF
	Specification document(s): [this document]		Specification document(s): [this document]
	Related information: none		Related information: none
	5. Security Considerations		5. Security Considerations
	This document defines particular uses of existing protocols for a		This document defines particular uses of existing protocols for a
	specific application. As such, it does not present new security		specific application. In particular, the basic protocol used for
	considerations.		this service is basic HTTP which is not secure without certain
			extensions. As such, the protocol described here does not itself
			present new security considerations.
	Security considerations relevant to email and email authentication		Security considerations relevant to email and email authentication
	can be found in most of the documents listed in the References		can be found in most of the documents listed in the References
	sections below. Information specific to use of reputation services		sections below. Information specific to use of reputation services
	can be found in [I-D.REPUTE-CONSIDERATIONS].		can be found in [I-D.REPUTE-CONSIDERATIONS].
	6. References		Reputation mechanisms represent an obvious security concern, in terms
			of the validity and use of the reputation information. These issues
			are beyond the scope of this specification.
			6. References
	6.1. Normative References		6.1. Normative References
	[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[I-D.REPUTE-MEDIA-TYPE]		[I-D.REPUTE-MEDIA-TYPE]
	Borenstein, N. and M. Kucherawy, "A Media Type for		Borenstein, N. and M. Kucherawy, "A Media Type for
	Reputation Interchange", draft-ietf-repute-media-type		Reputation Interchange", draft-ietf-repute-media-type
	(work in progress), November 2012.		(work in progress), November 2012.
	[I-D.REPUTE-MODEL]		[I-D.REPUTE-MODEL]
	Borenstein, N. and M. Kucherawy, "A Model for Reputation		Borenstein, N. and M. Kucherawy, "A Model for Reputation
	Interchange", draft-iet-repute-model (work in progress),		Interchange", draft-iet-repute-model (work in progress),
	November 2012.		November 2012.
	[KEYWORDS]		[KEYWORDS]
	Bradner, S., "Key words for use in RFCs to Indicate		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.
			[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
			Extensions (MIME) Part One: Format of Internet Message
			Bodies", RFC 2045, November 1996.
	[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", RFC 3986,		Resource Identifier (URI): Generic Syntax", RFC 3986,
	January 2005.		January 2005.
	[URI-TEMPLATE]		[URI-TEMPLATE]
	Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,		Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
	and D. Orchard, "URI Template", draft-gregorio-uritemplate		and D. Orchard, "URI Template", draft-gregorio-uritemplate
	(work in progress), September 2011.		(work in progress), September 2011.
	[WELL-KNOWN-URI]		[WELL-KNOWN-URI]
End of changes. 24 change blocks.
	43 lines changed or deleted		96 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/