One document matched: draft-ietf-repute-query-http-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="4" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-repute-query-http-00"
ipr="trust200902">
<front>
<title abbrev="Reputation Queries with HTTP and XML">
Reputation Data Interchange using HTTP and XML
</title>
<author fullname="Nathaniel Borenstein" initials="N." surname="Borenstein">
<organization>Mimecast</organization>
<address>
<postal>
<street>203 Crescent St., Suite 303</street>
<city>Waltham</city>
<region>MA</region>
<code>02453</code>
<country>USA</country>
</postal>
<phone>+1 781 996 5340</phone>
<email>nsb@guppylake.com</email>
</address>
</author>
<author fullname="Murray S. Kucherawy" initials="M. S." surname="Kucherawy">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>USA</country>
</postal>
<phone>+1 415 946 3800</phone>
<email>msk@cloudmark.com</email>
</address>
</author>
<date year="2011" />
<area>Applications</area>
<workgroup>REPUTE Working Group</workgroup>
<keyword>reputation</keyword>
<keyword>domain</keyword>
<keyword>security</keyword>
<keyword>messaging</keyword>
<keyword>dkim</keyword>
<keyword>spf</keyword>
<keyword>authentication</keyword>
<abstract>
<t> This document defines a mechanism to conduct queries for reputation
information using the Domain Name System. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> This memo defines a method to query a reputation data service
for information about an entity, using the HyperText Transfer Protocol
(HTTP) as the transport mechanism and XML as the payload format.
It is part of a series defining the overall reputation query/response
structure as well as the concept of reputation "vocabularies" for
particular applications. </t>
</section> <!-- Introduction -->
<section title="Terminology and Definitions" anchor="terms_and_defs">
<t>This section defines terms used in the rest of the document.</t>
<section title="Keywords" anchor="defs_keywords">
<t>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
<xref target="KEYWORDS"/>.</t>
</section> <!-- Keywords -->
<section title="Other Definitions" anchor="defs_other">
<t> Other terms of importance in this memo are defined in RFCxxxx, the
base memo in this document series. </t>
</section> <!-- Vocabulary -->
</section> <!-- Terminology and Definitions -->
<section title="Description" anchor="descr">
<section title="Query" anchor="query">
<t> A reputation query made via <xref target="HTTP"/> encodes the question
being asked partly in the <xref target="URI"/> and partly within the
GET instruction of the protocol. </t>
<t> The components to the question being asked comprise the following:
<list style="symbols">
<t> The subject of the query; </t>
<t> The name of the host, or the IP address, at which the
reputation service is available; </t>
<t> The name of the reputation application, i.e., the
context within which the query is being made; </t>
<t> Optionally, name(s) of the specific reputation assertions
or attributies that are being requested. </t>
</list> </t>
<t> The name of the application MUST be one registered with IANA. A
server receiving a query about an unregistered application or one
it does not explicitly support MUST return a 404 error code. </t>
<t> The syntax for the URI portion of the query is constructed using
a template as per <xref target="URI-TEMPLATE"/>. The following
variables MUST be available during template expansion:
<list style="hanging">
<t hangText="application:">
The name of the application reputation in whose
context the request is being made. </t>
<t hangText="scheme:">
The transport scheme the client will be using for
the query. </t>
<t hangText="service:">
The hostname or IP address being queried. </t>
</list> </t>
<t> Which scheme(s) can be used depends on how the reputation service
provider offers its services. Thus, the template could include
a specific schema 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 the client and server to negotiate out-of-band which
schemes are supported for client queries. Implementers should
be aware that the template could include a fixed scheme not supported
by the client. </t>
<t> The following variables are OPTIONAL, but might be required by the
template presented for a specific service:
<list style="hanging">
<t hangText="assertion:">
A list of one or more specific assertions of interest
to the client. If absent, the server MUST infer that
all available assertion information is being
requested. </t>
<t hangText="passwd:">
The "password" portion of a client credential. </t>
<t hangText="user:">
The "user" portion of a client credential. </t>
</list> </t>
<t> Other required or optional query parameters might be defined by
documents that register new vocabularies with IANA. </t>
<t> The template is retrieved by requesting the
<xref target="WELL-KNOWN-URI"/> "repute_template" from the
host providing reputation service using HTTP. If the template
cannot be retrieved, the query should be aborted and/or
retried at a later time. The server responding to the template
request SHOULD include an Expires field indicating a duration
for which the template should be considered valid by clients 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 not repeat the query. </t>
<t> For example, given the following template:
<figure><artwork>
{scheme}://{service}/{application}/{subject}/{assertion}
</artwork></figure> </t>
<t> 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 declares a required "subject" parameter,
requesting the "SENDS-SPAM" reputation assertion using HTTP to
conduct the query with no specific client authentication information
would be formed as follows:
<figure><artwork>
http://example.com/email-id/example.org/sends-spam
</artwork></figure> </t>
<t> Matching of the attribute name(s) MUST be case-insensitive. </t>
</section> <!-- Query -->
<section title="Response" anchor="response">
<t> The response is expected to be an XML document. The "format"
parameter of the "application/reputon" media type MUST be "xml"
when used in this mode. </t>
<t> The XML schema definition describing the format of that response is
included below. </t>
<section title="XML Schema" anchor="xml">
<t> The following XML schema describes the format of the reply:
<figure><artwork>
<?xml version="1.0" encoding="ISO-8859-1" ?%gt;
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- definition of local types -->
<xs:simpleType name="exttype">
<xs:restriction base="xs:token">
<xs:pattern value="\w+(-\w*)*:\s?[\w\p{P}]+"/>
<xs:/restriction>
<xs:/simpleType>
<!-- definition of simple elements -->
<xs:element name="rater" type="xs:token"/>
<xs:element name="rater-authenticity" type="xs:decimal"/>
<xs:element name="assertion" type="xs:token"/>
<xs:element name="extension" type="exttype"/>
<xs:element name="rated" type="xs:token"/>
<xs:element name="rating" type="xs:decimal"/>
<xs:element name="sample-size" type="xs:positiveInteger"/>
<xs:element name="updated" type="xs:positiveInteger"/>
<!-- definition of complex elements -->
<xs:complexType name="assertiontype">
<xs:sequence>
<xs:element ref="rater" minOccurs="1"/>
<xs:element ref="rater-authenticity" minOccurs="1"/>
<xs:element ref="assertion" minOccurs="1"/>
<xs:element ref="extension"/>
<xs:element ref="rated" minOccurs="1"/>
<xs:element ref="rating" minOccurs="1"/>
<xs:element ref="sample-size" minOccurs="1"/>
<xs:element ref="updated" minOccurs="1"/>
<xs:/sequence>
<xs:/complexType>
<xs:complexType name="reporttype">
<xs:sequence>
<xs:element name="reputon" type="assertiontype"
maxOccurs="unbounded" minOccurs="1"/>
<xs:/sequence>
<xs:/complexType>
<xs:element name="reputation" type="reporttype"/>
</xs:schema>
</artwork></figure> </t>
<t> The elements that comprise an "assertion" are used as follows:
<list style="hanging">
<t hangText="rater:"> The identity of the agent making the
assertion. </t>
<t hangText="rater-authenticity:"> An expression by the rater
of its confidence in the report it is giving.
Expressed as a decimal value between 0 and 1
inclusive. </t>
<t hangText="assertion:"> The assertion being made. This MUST
be an assertion registered within the specified
application by IANA. </t>
<t hangText="extension:"> (OPTIONAL) One or more
application-specific vocabulary extensions and
their corresponding values. If present, each of
these MUST be a vocabulary extension registered with
IANA. </t>
<t hangText="rated:"> The identity about which an assertion
is being made. </t>
<t hangText="rating:"> The value of the assertion. This
is a decimal number from 0 to 1, with 0 meaning
the assertion is completely false (according to the
agent making the assertion) and 1 meaning the
assertion is completely true. </t>
<t hangText="sample-size:"> The count of data points the
asserting agent used to produce the value provided
in the previous element. </t>
<t hangText="updated:"> The time at which the current rating
was computed. Expressed in number of seconds since
00:00:00 UTC, January 1, 1970. </t>
</list> </t>
</section> <!-- XML Schema -->
<section title="Example Reply" anchor="example">
<t> The following is an example reputon generated using the above schema,
including the media type definition line:
<figure><artwork>
Content-Type: application/reputon; app="email"; format="xml"
<?xml version="1.0" encoding="US-ASCII"?>
<reputation>
<reputon>
<rater>rep.example.net</rater>
<rater-authenticity>0.95</rater-authenticity>
<assertion>SENDS-SPAM</assertion>
<extension>IDENTITY: DKIM</extension>
<rated>example.com</rated>
<rating>0.0012</rating>
<sample-size>16938213</sample-size>
<updated>1317795852</updated>
</reputon>
</reputation>
</artwork></figure> </t>
<t> Here, reputation agent "rep.example.net" is asserting within
the context of email that "example.com" appears to send spam
1.2% of the time, based on just short of 17 million messages
analyzed or reported to date. The identity "example.com",
the subject of the query, is extracted from the analyzed
messages using the <xref target="DKIM"/> "d=" parameter for
messages where signatures validate. The reputation agent is 95%
confident of this result. (See [RFCxxxx+5] for details about the
registered email vocabulary.) </t>
</section> <!-- Example Reply -->
</section> <!-- Response -->
</section> <!-- Description -->
<section title="IANA Considerations" anchor="iana_considerations">
<t> This memo presents no actions for IANA. Registration of the
well-known URI "repute_template" will be done as defined in
<xref target="WELL-KNOWN-URI"/> which is not a function of IANA. </t>
</section> <!-- IANA Considerations -->
<section title="Security Considerations" anchor="sec_considerations">
<t> This memo describes security considerations introduced by the query
mechanism defined here. </t>
<t> [TBD] </t>
</section> <!-- Security Considerations -->
</middle>
<back>
<references title="Normative References">
<reference anchor="HTTP">
<front>
<title> Hypertext Transfer Protocol --
HTTP/1.1 </title>
<author initials="R." surname="Fielding"
fullname="R. Fielding">
<organization>
UC Irvine
</organization>
</author>
<author initials="J." surname="Gettys"
fullname="J. Gettys">
<organization>
Compaq/W3C
</organization>
</author>
<author initials="J." surname="Mogul"
fullname="J. Mogul">
<organization>
Compaq
</organization>
</author>
<author initials="H." surname="Frystyk"
fullname="H. Frystyk">
<organization>
W3C/MIT
</organization>
</author>
<author initials="L." surname="Masinter"
fullname="L. Masinter">
<organization>
Xerox
</organization>
</author>
<author initials="P." surname="Leach"
fullname="P. Leach">
<organization>
Microsoft
</organization>
</author>
<author initials="T." surname="Berners-Lee"
fullname="T. Berners-Lee">
<organization>
W3C/MIT
</organization>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor="KEYWORDS">
<front>
<title abbrev="RFC Key Words">Key words for
use in RFCs to Indicate Requirement
Levels</title>
<author initials="S." surname="Bradner"
fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="URI">
<front>
<title> Uniform Resource Identifier (URI):
Generic Syntax </title>
<author initials="T." surname="Berners-Lee"
fullname="T. Berners-Lee">
<organization>
W3C/MIT
</organization>
</author>
<author initials="R." surname="Fielding"
fullname="R. Fielding">
<organization>
Day Software
</organization>
</author>
<author initials="L." surname="Masinter"
fullname="L. Masinter">
<organization>
Adobe Systems
</organization>
</author>
<date month="January" year="2005"/>
</front>
<seriesInfo name="RFC" value="3986" />
</reference>
<reference anchor="URI-TEMPLATE">
<front>
<title> URI Template </title>
<author initials="J." surname="Gregorio"
fullname="J. Gregorio">
<organization>
Google
</organization>
</author>
<author initials="R." surname="Fielding"
fullname="R. Fielding">
<organization>
Adobe
</organization>
</author>
<author initials="M." surname="Hadley"
fullname="M. Hadley">
<organization>
MITRE
</organization>
</author>
<author initials="M." surname="Nottingham"
fullname="M. Nottingham">
<organization>
Rackspace
</organization>
</author>
<author initials="D." surname="Orchard"
fullname="D. Orchard">
<organization>
Salesforce.com
</organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="I-D" value="draft-gregorio-uritemplate" />
</reference>
<reference anchor="WELL-KNOWN-URI">
<front>
<title> Defining Well-Known Uniform
Resource Identifiers (URIs) </title>
<author initials="M." surname="Nottingham"
fullname="M. Nottingham">
<organization/>
</author>
<author initials="E." surname="Hammer-Lahav"
fullname="E. Hammer-Lahav">
<organization/>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="RFC" value="5785" />
</reference>
</references>
<references title="Informative References">
<reference anchor="DKIM">
<front>
<title> DomainKeys Identified Mail (DKIM)
Signatures </title>
<author initials="D." surname="Crocker"
fullname="D. Crocker" role="editor">
<organization>
Brandenburg InternetWorking
</organization>
</author>
<author initials="T." surname="Hansen"
fullname="T. Hansen" role="editor">
<organization>
AT&T Laboratories
</organization>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy" role="editor">
<organization>
Cloudmark
</organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="RFC" value="6376" />
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t> The authors would like to thank the following for their contributions
to this work:
Mark Nottingham,
and
David F. Skoll. </t>
</section>
<section title="Public Discussion" anchor="public">
<t> Public discussion of this suite of memos takes place on the
domainrep@ietf.org mailing list. See
https://www.ietf.org/mailman/listinfo/domainrep. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:26:04 |