One document matched: draft-roome-alto-pid-properties-03.xml

<?xml version="1.0"  encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://http://tools.ietf.org/tools/templates/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc iprnotified="no" ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
     docName="draft-roome-alto-pid-properties-03" 
     ipr="trust200902">
	<front>
		<title>PID Property Extension for ALTO Protocol</title>
		<author initials="W." surname="Roome" fullname="Wendy Roome">
			<organization abbrev="Alcatel-Lucent">Alcatel-Lucent/Bell Labs</organization>
			<address>
				<postal>
					<street>600 Mountain Ave, Rm 3B-324</street>
					<city>Murray Hill</city>
					<region>NJ</region>
					<code>07974</code>
					<country>USA</country>
				</postal>
				<phone>+1-908-582-7974</phone>
				<email>w.roome@alcatel-lucent.com</email>
			</address>
		</author>
		<author initials="Y." surname="Yang" fullname="Y. Richard Yang">
			<organization abbrev="Yale">Yale University</organization>
			<address>
				<postal>
					<street>51 Prospect St.</street>
					<city>New Haven</city>
					<region>CT</region>
					<country>USA</country>
				</postal>
				<email>yry@cs.yale.edu</email>
			</address>
		</author>
		<date day="23" month="January" year="2015"/>
		<area>Networks</area>
		<workgroup>ALTO WG</workgroup>
		<keyword>ALTO</keyword>
		<abstract>
			<t>
				This document extends the Application-Layer Traffic
				Optimization (ALTO) Protocol <xref
				target="RFC7285"/> by defining PID-based
				properties in much the same way that the original ALTO
				Protocol defined endpoint-based properties.
			</t>
		</abstract>
		<note title="Requirements Language">
		  <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="RFC2119">RFC 2119</xref>.</t>
		</note>
	</front>
	
	<middle>
		<section title="Introduction">
		
			<t>
				A key abstraction introduced by the ALTO Protocol <xref
				target="RFC7285"/> is a PID (Provider-defined
				Identifier): a named set of
				endpoint addresses. For IPv4/IPv6 networks,
				this set is defined by one or more endpoint address
				prefixes, or CIDRs <xref target="RFC4632"/>.
			</t>

			<t>
				An ALTO Server defines one or more Network Maps. Each Network Map
				is defined as a set of uniquely named PIDs,
				with the constraint that any given CIDR
				may appear in only one PID.
				Thus a Network Map logically partitions the space of endpoint addresses
				into groups defined by the PIDs.
			</t>
			<t>
				An ALTO Server may define several Network Maps, partitioning
				the endpoints in different ways. For example, one Network
				Map might partition endpoints according to geographical
				locations, with each PID representing the set of endpoints
				at a given location.
				Another Network Map might partition the endpoints according
				to their network capabilities
				(e.g., CDN delivery protocols such as HTTP or HTTPS).
				In this case, each PID defined in the Network Map represents
				endpoints with similar capabilities.
				</t>
				
			<t>
				Another abstraction introduced by the ALTO protocol is an Endpoint Property,
				which is a named value associated with an endpoint.
				Properties can include data such as
				the endpoint's ISP or ASN (Autonomous System Number),
				or the endpoint's latitude and longitude,
				or the country or continent codes for the endpoint's location.
				The ALTO protocol defines the mechanism for a client
				to query a server for these property values,
				but does not define the Endpoint Properties themselves;
				that is left to extensions.
			</t>
			
			<t>
				Just as Endpoint Properties are useful, it is reasonable to
				expect that it will be useful for sets of endpoints
				-- that is, PIDs -- to have properties as well.
				A PID Property might be an Endpoint Property shared by all endpoints
				in that PID (e.g., their ISP or ASN). Alternatively, a PID Property could
				be the aggregation of individual properties of the endpoints in the PID
				(e.g., the latitude and longitude of their geographic bounding box).
				Or a PID Property might simply be
				inherent in the way in which the ALTO Server defined the PID.
			</t>
			
			<t>
				However, the base ALTO protocol does not define the concept
				of PID Properties, or present a mechanism for a client
				to obtain PID Properties from an ALTO Server.
				This extension remedies that omission.
			</t>
		</section>

		<section title="The Consistency and Inheritance Design Views">
			<t>
				A key goal for defining PID Properties is that they
				should be consistent with, and generalize,
				Endpoint Properties. Specifically, in the base ALTO Protocol,
				the ALTO Server may associate a set of (name,value) pairs
				with any endpoint. These sets are the Endpoint Properties. 
				The ALTO Protocol specifies the mechanism for a client
				to retrieve those Endpoint Properties from a server.
			</t>
			
			<t>
				Consider the Endpoint Property PR and all endpoints defined
				in the PID P. If those endpoints all have the same
				value for PR, then the PID property PR for P should also have that same value.
			</t>
			<t>
				For the more general case,
				assume that P consists of the set of endpoint addresses {EPi},
				and EPi.PR is the value of property PR for endpoint EPi.
				Then we could obtain the value of PR for PID P by evaluating
				an aggregation function over the endpoint values {EPi.PR}.
				Typical aggregation functions include
				average/mean, mode, geo-center, union, bounding box, etc.,
				although of course the actual aggregation function would
				depend on the semantics of the property.
			</t>

			<t>
				Complementing the bottom-up aggregation view, we also adopt a
				top-down inheritance view.
				That is, if a property PR is not explicitly defined for an endpoint,
				but the endpoint's PID does define a value for PR,
				then the endpoint inherits the value of PID property.
				The concept of inheritance is a simple, but powerful
				concept to reduce information redundancy.
			</t>

		</section>
		
		<section title="PID Property Names">
			<t>
				PID Property names MUST follow the same rules
				as Global Endpoint Property names
				(Section 10.8.2 of <xref target="RFC7285"/>),
				and non-private names MUST be registered with IANA.
			</t>
			<t>
				Furthermore, PID Properties and Endpoint Properties
				share the same name space, and their definitions MUST be consistent.
				That is, if PR is used as both a PID Property and an Endpoint Property,
				then the semantics of PR as a PID Property
				must be clearly related to semantics of PR as an Endpoint Property.
				For example, when used as a PID Property,
				PR could be defined as the average
				(or some other representative value) of the values
				of PR for a set of endpoints.
			</t>
			<t>
				This document will use the type PIDPropertyType
				to indicate a string denoting a PID Property Name.
				This type is identical to EndpointPropertyType
				as defined in Section 10.8 of <xref target="RFC7285"/>.
			</t>
		</section>
		
		<section title="A Hierarchical View of a Network Map">

			<section title="Nested And Overlapping PIDs">
			
				<t>
					Each PID in a Network Map covers a set of endpoint addresses,
					and these sets can form a nested hierarchy.
					As an example, consider the following Network Map:
				</t>
	<figure>
	<artwork>
	<![CDATA[
    PID p0:  [0.0.0.0/0, ::0/0]
    PID p1:  [1.0.0.0/8]
    PID p2a: [1.0.0.0/16]
    PID p2b: [1.1.0.0/16]
	]]>
	</artwork>
	</figure>
        
				<t>
					Every endpoint in p2a and p2b is also in the set covered by p1,
					and every possible IPV4 endpoint is also covered by PID p0.
					We would like to take advantage of this hierarchy
					to allow PIDs to inherit properties,
					just as a class in an object oriented programming language
					inherits attributes from its parent class.
					In the example, it is reasonable to expect
					that PIDs p2a and p2b would inherit any property
					of p1 that they do not override,
					and every PID would inherit the properties of PID p0.
				</t>
	
				<t>
					Note that when calculating costs, the ALTO Protocol
					requires every endpoint to be in one, and only one, PID.
					The ALTO Protocol resolves this by using the "longest match" rule.
					That is, the ALTO Protocol says when an endpoint address
					is covered by more than one prefix, the address is in the PID
					with the prefix with the longest mask.
					Because any given prefix can be on only one PID,
					this ensures each endpoint is in only one PID.
					Thus in our example, 1.0.0.1 is in p2a, 1.1.0.1 is in p2b,
					and 1.2.0.1 in in p1.
				</t>
			
				<t>
					However, while PIDs can nest within other PIDs,
					they do not necessarily form a simple hierarchy.
					Suppose we add PID p3 to the previous Network Map:
				</t>
			
	<figure>
	<artwork>
	<![CDATA[
    PID p0:  [0.0.0.0/0, ::0/0]
    PID p1:  [1.0.0.0/8]
    PID p2a: [1.0.0.0/16]
    PID p2b: [1.1.0.0/16]
    PID p3:  [1.0.255.0/24, 1.1.0.0/24]
	]]>
	</artwork>
	</figure>
				
				<t>
					Some endpoints in p3 are in p2a, and others are in p2b.
					Thus p3 is partially contained in PIDs p2a and p2b,
					without being completely contained in either.
					So we would not expect p3 to inherit properties from p2a or p2b.
					But p3 is completely contained in p1 and p0,
					so it is reasonable to expect p3 to inherit
					properties from p1 and p0 that are not overridden in p2a or p2b.
					In short, "PID inheritance" raises issues similar
					to those of "multiple inheritance"
					in object oriented programming languages.
				</t>
			</section>

			<section title="Definition Of PID Property Inheritence"
						anchor="InheritanceAlgorithm">
				<t>
					While PID inheritance raises some complications, it is too useful
					to ignore. Fortunately CIDRs do form a simple
					"single parent" hierarchy, so we will use CIDR inheritance
					as the basis for defining PID inheritance. We believe this
					preserves the useful cases, and avoids the pathological
					ones.
				</t>
				<t>
					Note that the ALTO Protocol did not define "PID
					inheritance" because it was not relevant to the base protocol.
				</t>
				<t>
				<list style="hanging">
					<t hangText="Definition:">
						A parent of CIDR C is any CIDR,
						in the set of CIDRs for all PIDs in the Network Map,
						which covers all endpoints covered by C,
						and whose mask is shorter than the mask of C.
					</t>
					<t hangText="Definition:">
						The immediate parent of CIDR C
						is the parent of C with the longest prefix.
						The immediate parent CIDR might not exist,
						but if it does, it is unique.
					</t>
					<t hangText="Definition:">
						A CIDR C inherits the value V for property PR
						if the PID containing its immediate parent CIDR
						defines the value V for property PR,
						or if its immediate parent CIDR inherits
						the value V for property PR.
					</t>
					<t hangText="Definition:">
						A PID P has the value V for property PR
						if PR is explicitly defined with value V in P,
						or if every CIDR C in P inherits the same value V for PR.
					</t>
				</list>
				</t>

				<t>
					Suppose the following properties are defined for PIDs described above:
				</t>
		
				<figure>
				<artwork>
				<![CDATA[
    PID p1:  ISP="Verizon" country="us"
    PID p2a: ASN="12345" state="NJ"
    PID p2b: ASN="12345" state="CT"
    ]]>
				</artwork>
				</figure>
		
				<t>
					Then p2a, p2b, and p3 all inherit the "ISP" and
					"country" properties from p1, because those properties are not
					defined for p2a or p2b. p3 would inherit "12345" for the
					"ASN" property, because although p2a and p2b both
					define that property, they give it the same value. However,
					p3 would not inherit the "state" property, because it has
					different values in p2a and p2b.
				</t>

			</section>
		</section>
		
		<section title="Protocol Specification: New Service Information Resources">
			<t>
				This document defines two new ALTO resources.
				The PID Property Map returns the values of a set of properties
				for all PIDs in a Network Map.
				The Filtered PID Property Map returns PID Properties
				for a subset of PIDs and properties selected by the client.
				These are analogous to the Full and Filtered
				Network Maps in the base ALTO Protocol.
			</t>
			<t>
				An ALTO Server may provide any number of resource of these types,
				provided that they have unique capabilities.
				For example, an ALTO Server may offer several Full PID Property Maps,
				for the same Network Map,
				as long as each one returns a different set of properties.
			</t>
			<t>
				Both services are optional.
				In particular, an ALTO Server may provide a Full PID Property Map
				without providing a corresponding Filtered PID Property Map,
				and vice versa.
			</t>

		<section title="Full PID Property Map" anchor="FullPidPropMapService">
			<t>
				A Full PID Property Map returns the properties defined
				for all PIDs in a Network Map.
			</t>
			<section title="Media Type" anchor="PIDPropMediaType">
				<t>
					The media type of an ALTO PID Property Map resource is
					"application/alto-pidprop+json".
				</t>
			</section>
			<section title="HTTP Method">
				<t>
					An ALTO PID Property Map resource is requested using the HTTP GET method.
				</t>
			</section>
			<section title="Accept Input Parameters">
				<t>
				None.
				</t>
			</section>
			<section title="Capabilities">
				<t>
					The capabilities are defined by an object of type PIDPropertyCapabilities:
				</t>
			<figure>
			  <artwork><![CDATA[
  object {
    PIDPropertyType prop-types<1..*>;
  } PIDPropertyCapabilities;
]]></artwork>
			</figure>
				<t>
					where "prop-types" is an array with the names
					of the PID Properties returned by this resource.
				</t>
			</section>
			<section title="Uses">
				<t>
					An array with the resource-id of the Network Map
					which defines the PIDs whose properties are returned.
				</t>
			</section>
			<section title="Response" anchor="FullPidPropResponse">
				<t>
					The "dependent-vtags" field in the "meta" field of the
					response MUST be an array that includes the version tag of
					the ALTO Network Map defining these PIDs.
				</t>
				<t>
					The data component of a PID Properties response
					is named "pid-properties", which is a JSON object
					of type PIDPropertyMapData, where:
				</t>
			<figure>
			<artwork><![CDATA[
   object {
     PIDPropertyMapData pid-properties;
   } InfoResourcePIDProperties : ResponseEntityBase;
   
   object-map {
     PIDName -> PIDProps;
   } PIDPropertyMapData;
   
   object {
     PIDPropertyType -> JSONValue;
   } PIDProps
]]></artwork>
			</figure>
				<t>
					The PIDName and ResponseEntityBase types are defined
					in Sections 10.1 and 8.4 of the
					<xref target="RFC7285">ALTO Protocol</xref>.
				</t>
				<t>
					Specifically, a PIDPropertyMapData object has one member for
					each PID in the Network Map. The PID's properties are
					encoded in the corresponding PIDProps object. PIDProps
					encodes one name/value pair for each property, where the
					property names are encoded as strings of type
					PIDPropertyType. A protocol implementation SHOULD assume
					that the property value is a JSONString and fail to parse if
					it is not, unless the implementation is using an extension
					to this document that indicates when and how property values
					of other data types are signaled.
				</t>
				<t>
					For each PID in the Network Map, the ALTO Server returns the
					value defined for each of the PID Properties specified in
					this resource's "capabilities" list. For efficiency, the
					ALTO Server SHOULD omit property values that are inherited
					rather than explicitly defined. The client SHOULD use the
					algorithm defined in <xref target="InheritanceAlgorithm"/>
					to determine inherited property values.
				</t>
				<t>
					An ALTO Server MAY explicitly define a property as not having
					a value for a particular PID.
					That is, a server may say that a property is "defined to have no value",
					as opposed to the property being "undefined".
					In this case,
					if the PID would not inherit a value for that property,
					then the ALTO Server MUST either omit the property,
					or else return a "null" value for it.
					However, if that PID would inherit a value for that property,
					then the ALTO server MUST return a "null" value.
					An ALTO Client MUST recognize a "null" value as meaning "do not
					apply the inheritance rules for this property in the PID."
				</t>
				<t>
					If the ALTO Server does
					not define any properties for a PID, then the server MAY omit that
					PID from the response.
				</t>
			</section>
			<section title="Example">
				<t>
					The following example uses the Network Map and PID Properties
					defined above. Note that the response does not include entries
					for PIDs p0 or p3. The former was omitted because no properties
					were defined for it, and the latter because its
					only properties are inherited.
				</t>
			<figure>
			<artwork><![CDATA[
  GET /pidprop/full HTTP/1.1
  Host: alto.example.com
  Accept: application/alto-pidprop+json,application/alto-error+json


  HTTP/1.1 200 OK
  Content-Length: ###
  Content-Type: application/alto-pidprop+json
  {
    "meta" : {
      "dependent-vtags" : [
        {"resource-id": "my-default-network-map",
         "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
        }
      ]
    },
    "pid-properties": {
      "p1" : { "ISP": "Verizon", "country": "us" },
      "p2a": { "ASN": "12345", "state": "NJ" },
      "p2b": { "ASN": "12345", "state": "CT" }
    }
  }
]]></artwork>
</figure>
			</section>
		</section>	

		<section title="Filtered PID Property Map" anchor="FilteredPidPropMapService">
			<t>
				A Filtered PID Property Map returns the values
				for set of PIDs and properties selected by the client.
			</t>
			<section title="Media Type">
				<t>
					The media type of an ALTO Filtered PID Property Map resource is
					the same as a Full PID Property Map,
					and is defined in <xref target="PIDPropMediaType"/>.
				</t>
			</section>
			<section title="HTTP Method">
				<t>
					An ALTO Filtered PID Property Map resource is requested
					using the HTTP POST method.
				</t>
			</section>
			<section title="Accept Input Parameters" anchor="PIDPropParams">
				<t>
					The input parameters for a Filtered PID Property Map request are
					supplied in the entity body of the POST request. This
					document specifies the input parameters with a data format
					indicated by the media type
					"application/alto-pidpropparams+json", which is a JSON
					object of type ReqPIDProp:
				</t>
			<figure>
			  <artwork><![CDATA[
  object {
    PIDPropertyType properties<1..*>;
    PIDName         pids<1..*>
  } ReqPIDProp;
]]></artwork>
			</figure>
				<t>
					with fields:
					<list style="hanging">

					<t hangText="properties:">List of PID properties to be
					returned for each PID. Each specified property MUST
					be included in the list of supported properties indicated
					by this resource's "capabilities" field
					(<xref target="FilteredPIDPropCapabilities" />).  The ALTO
					server MUST interpret entries appearing multiple times as
					if they appeared only once.
					</t>

					<t hangText="pids:">List of PID names for
					which the specified properties are to be returned. The
					ALTO server MUST interpret entries appearing multiple
					times as if they appeared only once.
					</t>

					</list>
				</t>
			</section>
			<section title="Capabilities" anchor="FilteredPIDPropCapabilities">
				<t>
					The capabilities are defined by an object of type PIDPropertyCapabilities,
					as defined above.
				</t>
			</section>
			<section title="Uses">
				<t>
					An array with the resource-id of the Network Map
					which defines the PIDs whose properties are returned.
				</t>
			</section>
			<section title="Response">
				<t>
					The response is the same as for the Full PID Property Map
					(<xref target="FullPidPropResponse"/>),
					except that it only includes the properties and PIDs
					requested by the client.
				</t>
				<t>
					Also, Filtered PID Property Map response MUST include
					all inherited PID property values
					(unlike the Full PID Property Map, the Filtered PID Property Map response
					does not include enough information for the client to calculate
					the inherited values).
				</t>
			</section>
			<section title="Example">
				<t>
					The following example uses the Network Map and PID Properties
					defined above. Note that the response includes the inherited
					property "ISP" for PID p2a, and "state" and "ISP" for p3.
				</t>
			<figure>
			<artwork><![CDATA[
  POST /pidprop/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: ###
  Content-Type: application/alto-pidpropparams+json
  Accept: application/alto-pidprop+json,application/alto-error+json

  {
    "properties" : [ "ISP", "ASN", "state" ]",
    "pids" : [ "p1", "p2a", "p3" ]
  }


  HTTP/1.1 200 OK
  Content-Length: ###
  Content-Type: application/alto-pidprop+json
  {
    "meta" : {
      "dependent-vtags" : [
        {"resource-id": "my-default-network-map",
         "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
        }
      ]
    },
    "pid-properties" : {
      "p1" : { "ISP": "Verizon" },
      "p2a": { "ISP": "Verizon", "ASN": "12345", "state": "NJ" },
      "p3" : { "ISP": "Verizon", "ASN": "12345" }
    }
  }
]]></artwork>
</figure>
			</section>
		</section>
		</section>

		<section title="IRD Example">
			<t>
				Here is an example of an ALTO Information Resource Directory (IRD)
				which defines several PID Property resources.
				Note that "full-pid-property-map" returns
				several PID Properties for all PIDs in the Network Map,
				while "asn-pid-property-map" returns just the ASN property.
				The resource "filtered-pid-properties" resource
				returns values for properties and PIDs selected by the client. 
			</t>

        <figure>
        <artwork>
          <![CDATA[
  ...
  "resources" : {
     "my-default-network-map" : {
        "uri" : "http://alto.example.com/networkmap",
        "media-type" : "application/alto-networkmap+json" 
     },
     "endpoint-property" : {
        "uri" : "http://alto.example.com/endpointprop/lookup",
        "media-type" : "application/alto-endpointprop+json",
        "accepts" : "application/alto-endpointpropparams+json",
        "capabilities" : {
          "prop-types" : [ "my-default-network-map.pid",
                           "priv:ietf-example-prop" ]
        },
     },
     "full-pid-property-map" : {
        "uri" : "http://alto.example.com/pidprop/full",
        "media-type" : "application/alto-pidprop+json",
        "uses" : ["my-default-network-map" ]
        "capabilities" : {
          "prop-types" : [ "ISP", "country", "ASN", "state" ]
        },
     }
     "asn-pid-property-map" : {
        "uri" : "http://alto.example.com/pidprop/asn",
        "media-type" : "application/alto-pidprop+json",
        "uses" : ["my-default-network-map" ]
        "capabilities" : {
          "prop-types" : [ "ASN" ]
        },
     }
     "filtered-pid-properties" : {
        "uri" : "http://alto.example.com/pidprop/lookup",
        "media-type" : "application/alto-pidprop+json",
        "accepts" : "application/alto-pidpropparams+json",
        "uses" : ["my-default-network-map" ]
        "capabilities" : {
          "prop-types" : [ "ISP", "country", "ASN", "state" ]
        },
     }
  }  
      ]]>
        </artwork>
        </figure>

      </section>

		<section title="Extensions To Endpoint Property Service">
			<t>
				As described in Section 10.8 of <xref target="RFC7285"/>,
				Endpoint Property names may be prefixed with the Resource ID of
				a Network Map. For such resource-specific properties, if a value
				is not explicitly defined for an endpoint, the Endpoint Property
				Service MUST return the value that a PID Property Map would
				return for the PID containing that endpoint.
			</t>
			
			<t>
				For property names that are not prefixed by a Network Map
				Resource ID, if a value is not defined for an endpoint, the
				Endpoint Property Service MAY return the value defined for that
				property in one of the ALTO Server's PID Property Maps for the
				PID containing the endpoint.
			</t>
		</section>

		<section title="Security Considerations">
			<t>
				As with Endpoint Properties, PID Properties may have sensitive
				customer-specific information. If this is the case, an ALTO
				Server may limit access to those properties by providing several
				different PID Property services. For non-sensitive properties,
				the ALTO Server would provide a URI which accepts requests from
				any client. Sensitive properties, on the other hand, would only
				be available via a secure URI which would require client
				authentication.
			</t>
		</section>

		<section anchor="IANA" title="IANA Considerations">
			<t>
				This document defines additional application/alto-* media types,
				and extends the ALTO endpoint property registry.
			</t>

			<section title="application/alto-* Media Types">
			<t>This document registers two additional ALTO media types, listed
			in
			<xref target="TableMediaTypes" />.</t>

			<texttable anchor="TableMediaTypes" title="Additional ALTO Media Types">
			  <ttcol>Type</ttcol>
			  <ttcol>Subtype</ttcol>
			  <ttcol>Specification</ttcol>
			  <c>application</c>
			  <c>alto-pidprop+json</c>
			  <c>
				<xref target="PIDPropMediaType" />
			  </c>
			  <c>application</c>
			  <c>alto-pidpropparams+json</c>
			  <c>
				<xref target="PIDPropParams" />
			  </c>
			</texttable>
			<t>
			  <list style="hanging" hangIndent="3">
				<t hangText="Type name:">application</t>
				<t hangText="Subtype name:">This documents registers
				multiple subtypes, as listed in
				<xref target="TableMediaTypes" />.</t>
				<t hangText="Required parameters:">n/a</t>
				<t hangText="Optional parameters:">n/a</t>
				<t hangText="Encoding considerations:">Encoding considerations are
				identical to those specified for the "application/json" media type. See

				<xref target="RFC7159" />.</t>
				<t hangText="Security considerations:">Security considerations relating
				to the generation and consumption of ALTO Protocol messages are
				discussed in
				Section 15 of <xref target="RFC7285"/>.</t>
				<t hangText="Interoperability considerations:">This document specifies
				format of conforming messages and the interpretation thereof.</t>
				<t hangText="Published specification:">This document is the
				specification for these media types; see
				<xref target="TableMediaTypes" /> for the section documenting each media
				type.</t>


				<t hangText="Applications that use this media type:">ALTO servers and
				ALTO clients either stand alone or are embedded within other
				applications.</t>
				<t hangText="Additional information:">
				  <list style="hanging" hangIndent="3">
					<t hangText="Magic number(s):">n/a</t>
					<t hangText="File extension(s):">This document uses the mime type
					to refer to protocol messages and thus does not require a file
					extension.</t>
					<t hangText="Macintosh file type code(s):">n/a</t>
				  </list>
				</t>
				<t hangText="Person & email address to contact for further information:">
				See Authors' Addresses section.</t>
				<t hangText="Intended usage:">COMMON</t>
				<t hangText="Restrictions on usage:">n/a</t>
				<t hangText="Author:">See Authors' Addresses section.</t>
				<t hangText="Change controller:">Internet Engineering Task Force (mailto:iesg@ietf.org).</t>
			  </list>
			</t>
			</section>
			<section title="ALTO Endpoint Property Type Registry" anchor="IANAEndpointProp">
				<t>
					The ALTO Endpoint Property Type Registry
					was created by <xref target="RFC7285"/>.
					If possible, the name of that registry should be changed to
					"ALTO Property Type Registry", to indicate that it
					is not restricted to Endpoint Properties.
					If it is not feasible to change the name,
					the description must be amended to indicate
					that it registers PID Properties
					as well as Endpoint Properties.
				</t>
			</section>
 
		</section>

	</middle>
	
	<back>
		<references>
			<reference anchor='RFC2119'>
				<front>
					<title abbrev='HTTP'>Key words for use in RFCs to Indicate Requirement Levels</title>
					<author initials='S.' surname='Bradner' fullname='S. Bradner' />
					<date year='1997' month='March' />
				</front>
				<seriesInfo name='RFC' value='2119' />
				<seriesInfo name='BCP' value='14' />
				<format type='TXT' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
			</reference>
			<reference anchor="RFC4632">
				<front>
					<title>Classless Inter-domain Routing (CIDR):
						The Internet Address Assignment and Aggregation Plan</title>
					<author initials="V." surname="Fuller" fullname="V. Fuller"/>
					<author initials="T." surname="Li" fullname="T. Li"/>
					<date month="August" year="2006"/>
				</front>
				<seriesInfo name="RFC" value="4632" />
				<seriesInfo name="BCP" value="122" />
			</reference>
			<reference anchor="RFC7159">
				<front>
					<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
					<author initials="T." surname="Bray" fullname="T. Bray"/>
					<date month="March" year="2014"/>
				</front>
				<seriesInfo name="RFC" value="7159" />
			</reference>
			<reference anchor="RFC7285">
				<front>
					<title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
					<author initials="R." surname="Almi" fullname="R. Alimi"/>
					<author initials="R." surname="Penno" fullname="R. Penno"/>
					<author initials="Y." surname="Yang" fullname="Y. Yang"/>
					<author initials="S." surname="Kiesel" fullname="S. Kiesel"/>
					<author initials="S." surname="Previdi" fullname="S. Previdi"/>
					<author initials="W." surname="Roome" fullname="W. Roome"/>
					<author initials="S." surname="Shalunov" fullname="S. Shalunov"/>
					<author initials="R." surname="Woundy" fullname="R. Woundy"/>
					<date month="September" year="2014"/>
				</front>
				<seriesInfo name="RFC" value="7285" />
			</reference>
		</references>
	</back>
</rfc>