HTML Standard Tracker

Filter

File a bug

SVNBugCommentTime (UTC)
4091Add IANA considerations sections for HTTP headers.2009-10-06 10:02
@@ -6866,24 +6866,24 @@ interface <dfn>HTMLDocument</dfn> {
   <p>All the numeric components above, other than the year, must be
   given as two digits in the range U+0030 DIGIT ZERO (0) to U+0039
   DIGIT NINE (9) representing the number in base ten, zero-padded if
   necessary. The year must be given as four or more digits in the
   range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) representing
   the number in base ten, zero-padded if necessary.</p>
 
   <p>The <code>Document</code>'s source file's last modification date
   and time must be derived from relevant features of the networking
   protocols used, e.g. from the value of the HTTP <code
-  title="">Last-Modified</code> header of the document, or from
-  metadata in the file system for local files. If the last
-  modification date and time are not known, the attribute must return
-  the current date and time in the above format.</p>
+  title="http-last-modified">Last-Modified</code> header of the
+  document, or from metadata in the file system for local files. If
+  the last modification date and time are not known, the attribute
+  must return the current date and time in the above format.</p>
 
   <hr>
 
   </div>
 
   <dl class="domintro">
 
    <dt><var title="">document</var> . <code title="dom-document-compatmode">compatMode</code></dt>
    <dd>
     <p>In a conforming document, returns the string "<code
@@ -73088,23 +73088,23 @@ interface <dfn>EventSource</dfn> {
   <p>The resource indicated in the argument to the <code
   title="dom-EventSource">EventSource</code> constructor is <span
   title="fetch">fetched</span> when the constructor is run.</p>
 
   <p>For HTTP connections, the <code title="">Accept</code> header may
   be included; if included, it must contain only formats of event
   framing that are supported by the user agent (one of which must be
   <code>text/event-stream</code>, as described below).</p>
 
   <p>If the event source's last event ID string is not the empty
-  string, then a <code title="">Last-Event-ID</code> HTTP header must
-  be included with the request, whose value is the value of the event
-  source's last event ID string.</p>
+  string, then a <code title="http-last-event-id">Last-Event-ID</code>
+  HTTP header must be included with the request, whose value is the
+  value of the event source's last event ID string.</p>
 
   <p>User agents should use the <code>Cache-Control: no-cache</code>
   header in requests to bypass any caches for requests of event
   sources. User agents should ignore HTTP cache headers in the
   response, never caching event sources.</p>
 
   <p>User agents must act as if the connection had failed due to a
   network error if the <span>origin</span> of the <span>URL</span> of
   the resource to be <span title="fetch">fetched</span> is not the
   <span>same origin</span> as that of the <span>first script</span>
@@ -73487,29 +73487,30 @@ stocks.onmessage = function (event) {
   </div>
 
   <div class="example">
 
    <p>The following stream contains four blocks. The first block has
    just a comment, and will fire nothing. The second block has two
    fields with names "data" and "id" respectively; an event will be
    fired for this block, with the data "first event", and will then
    set the last event ID to "1" so that if the connection died between
    this block and the next, the server would be sent a <code
-   title="">Last-Event-ID</code> header with the value "1". The third
-   block fires an event with data "second event", and also has an "id"
-   field, this time with no value, which resets the last event ID to
-   the empty string (meaning no <code title="">Last-Event-ID</code>
-   header will now be sent in the event of a reconnection being
-   attempted). Finally, the last block just fires an event with the
-   data "third event". Note that the last block doesn't have to end
-   with a blank line, the end of the stream is enough to trigger the
-   dispatch of the last event.</p>
+   title="http-last-event-id">Last-Event-ID</code> header with the
+   value "1". The third block fires an event with data "second event",
+   and also has an "id" field, this time with no value, which resets
+   the last event ID to the empty string (meaning no <code
+   title="http-last-event-id">Last-Event-ID</code> header will now be
+   sent in the event of a reconnection being attempted). Finally, the
+   last block just fires an event with the data "third event". Note
+   that the last block doesn't have to end with a blank line, the end
+   of the stream is enough to trigger the dispatch of the last
+   event.</p>
 
    <pre>: test stream
 
 data: first event
 id: 1
 
 data: second event
 id
 
 data: third event</pre>
@@ -73601,25 +73602,25 @@ data:&nbsp;test</pre>
   reference from the <code>Window</code> or <code>WorkerUtils</code>
   object that the <code>EventSource</code> object's constructor was
   invoked from to the <code>EventSource</code> object itself.</p>
 
   <p>If an <code>EventSource</code> object is garbage collected while
   its connection is still open, the connection must be closed.</p>
 
 
   <h4>IANA considerations</h4>
 
+  <h3><dfn><code>text/event-stream</code></dfn></h3>
+
   <p>This registration is for community review and will be submitted
   to the IESG for review, approval, and registration with IANA.</p>
 
-  <h3><dfn><code>text/event-stream</code></dfn></h3>
-
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type text/event-stream
   -->
 
   <dl>
    <dt>Type name:</dt>
    <dd>text</dd>
    <dt>Subtype name:</dt>
    <dd>event-stream</dd>
@@ -73683,20 +73684,44 @@ data:&nbsp;test</pre>
    are not expected to be labeled with this type.</dd>
    <dt>Author:</dt>
    <dd>Ian Hickson &lt;ian@hixie.ch></dd>
    <dt>Change controller:</dt>
    <dd>W3C</dd>
   </dl>
 
   <p>Fragment identifiers have no meaning with
   <code>text/event-stream</code> resources.</p>
 
+
+  <h3><dfn title="http-last-event-id"><code>Last-Event-ID</code></dfn></h3>
+
+  <p>This section describes a header field for registration in the
+  Permanent Message Header Field Registry.  <a
+  href="#refsRFC3864">[RFC3864]</a></p>
+
+  <dl>
+   <dt>Header field name</dt>
+   <dd>Last-Event-ID</dd>
+   <dt>Applicable protocol</dt>
+   <dd>http</dd>
+   <dt>Status</dt>
+   <dd>standard</dd>
+   <dt>Author/Change controller</dt>
+   <dd>W3C</dd>
+   <dt>Specification document(s)</dt>
+   <dd>
+    This document is the relevant specification.
+   </dd>
+   <dt>Related information</dt>
+   <dd>None.</dd>   
+  </dl>
+
   <!--END eventsource--><!--START html5-->
 
 
 
   <h3 id="network"><dfn>Web sockets</dfn></h3> <!--START websocket--><!--START websocket-api--><!--END html5-->
 
   <h4 id="network-intro">Introduction</h4>
 
   <p><i>This section is non-normative.</i></p>
 
@@ -74782,70 +74807,74 @@ Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE=</pre>
 
     <p class="note">This skips past the LF byte of the CRLF after the
     blank line after the headers.</p>
 
    </li>
 
    <li>
 
     <p>If <var title="">mode</var> is <i title="">normal</i>, then: If
     there is not exactly one entry in the <var title="">headers</var>
-    list whose name is "<code title="">websocket-origin</code>", or if
+    list whose name is "<code
+    title="http-websocket-origin">websocket-origin</code>", or if
     there is not exactly one entry in the <var title="">headers</var>
-    list whose name is "<code title="">websocket-location</code>", or
-    if the <var title="">protocol</var> was specified but there is not
+    list whose name is "<code
+    title="http-websocket-location">websocket-location</code>", or if
+    the <var title="">protocol</var> was specified but there is not
     exactly one entry in the <var title="">headers</var> list whose
-    name is "<code title="">websocket-protocol</code>", or if there
-    are any entries in the <var title="">headers</var> list whose
-    names are the empty string, then <span>fail the Web Socket
+    name is "<code
+    title="http-websocket-protocol">websocket-protocol</code>", or if
+    there are any entries in the <var title="">headers</var> list
+    whose names are the empty string, then <span>fail the Web Socket
     connection</span> and abort these steps. Otherwise, handle each
     entry in the <var title="">headers</var> list as follows:</p>
 
     <dl class="switch">
 
      <dt>If the entry's name is "<code
-     title="">websocket-origin</code>"</dt>
+     title="http-websocket-origin">websocket-origin</code>"</dt>
 
      <dd><p>If the value is not exactly equal to <var
      title="">origin</var>, <span>converted to ASCII lowercase</span>,
      then <span>fail the Web Socket connection</span> and abort these
      steps. <a href="#refsORIGIN">[ORIGIN]</a></p></dd>
 
 
      <dt>If the entry's name is "<code
-     title="">websocket-location</code>"</dt>
+     title="http-websocket-location">websocket-location</code>"</dt>
 
      <dd>
 
       <p>If the value is not exactly equal to a string obtained from
       the steps to <span>construct a Web Socket URL</span> from <var
       title="">host</var>, <var title="">port</var>, <var
       title="">resource name</var>, and the <var title="">secure</var>
       flag, then <span>fail the Web Socket connection</span> and abort
       these steps.</p>
 
      </dd>
 
 
      <dt>If the entry's name is "<code
-     title="">websocket-protocol</code>"</dt>
+     title="http-websocket-protocol">websocket-protocol</code>"</dt>
 
      <dd><p>If there was a <var title="">protocol</var> specified, and
      the value is not exactly equal to <var title="">protocol</var>,
      then <span>fail the Web Socket connection</span> and abort these
      steps. (If no <var title="">protocol</var> was specified, the
      header is ignored.)</p></dd>
 
 
-     <dt>If the entry's name is "<code title="">set-cookie</code>" or
-     "<code title="">set-cookie2</code>" or another cookie-related
-     header name</dt>
+     <dt>If the entry's name is "<code
+     title="http-setcookie2">set-cookie</code>" or "<code
+     title="http-setcookie2">set-cookie2</code>" or another
+     cookie-related header name</dt>
 
      <dd><p>Handle the cookie as defined by the appropriate
      specification, with the resource being the one with the host <var
      title="">host</var>, the port <var title="">port</var>, the path
      (and possibly query parameters) <var title="">resource
      name</var>, and the scheme <code title="">http</code> if <var
      title="">secure</var> is false and <code title="">https</code> if
      <var title="">secure</var> is true. <a
      href="#refsRFC2109">[RFC2109]</a> <a
      href="#refsRFC2965">[RFC2965]</a></p></dd>
@@ -75131,37 +75160,39 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
   open a connection and send the following bytes back to the
   client:</p>
 
   <pre>48 54 54 50 2F 31 2E 31  20 31 30 31 20 57 65 62
 20 53 6F 63 6B 65 74 20  50 72 6F 74 6F 63 6F 6C
 20 48 61 6E 64 73 68 61  6B 65 0D 0A 55 70 67 72
 61 64 65 3A 20 57 65 62  53 6F 63 6B 65 74 0D 0A
 43 6F 6E 6E 65 63 74 69  6F 6E 3A 20 55 70 67 72
 61 64 65 0D 0A</pre>
 
-  <p>Send the string "<code title="">WebSocket-Origin</code>" followed
-  by a U+003A COLON (:) and a U+0020 SPACE, followed by the <span
+  <p>Send the string "<code
+  title="http-websocket-origin">WebSocket-Origin</code>" followed by a
+  U+003A COLON (:) and a U+0020 SPACE, followed by the <span
   title="ASCII serialization of an origin">ASCII serialization</span>
   of the origin from which the server is willing to accept
   connections, followed by a CRLF pair (0x0D 0x0A). <a
   href="#refsORIGIN">[ORIGIN]</a></p>
 
   <div class="example">
 
    <p>For instance:</p>
 
    <pre>WebSocket-Origin: http://example.com</pre>
 
   </div>
 
-  <p>Send the string "<code title="">WebSocket-Location</code>"
-  followed by a U+003A COLON (:) and a U+0020 SPACE, followed by the
+  <p>Send the string "<code
+  title="http-websocket-location">WebSocket-Location</code>" followed
+  by a U+003A COLON (:) and a U+0020 SPACE, followed by the
   <span>URL</span> of the Web Socket script, followed by a CRLF pair
   (0x0D 0x0A).</p>
 
   <div class="example">
 
    <p>For instance:</p>
 
    <pre>WebSocket-Location: ws://example.com/demo</pre>
 
   </div>
@@ -75186,22 +75217,22 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
   client during the handshake.</p>
 
   <p>The data sent by the client consists of a number of fields
   separated by CR LF pairs (bytes 0x0D 0x0A).</p>
 
   <p>The first field consists of three tokens separated by space
   characters (byte 0x20). The middle token is the path being
   opened. If the server supports multiple paths, then the server
   should echo the value of this field in the initial handshake, as
   part of the <span>URL</span> given on the <code
-  title="">WebSocket-Location</code> line (after the appropriate
-  scheme and host).</p>
+  title="http-websocket-location">WebSocket-Location</code> line
+  (after the appropriate scheme and host).</p>
 
   <p>If the first field does not have three tokens, the server should
   abort the connection as it probably represents an errorneous
   client.</p>
 
   <hr>
 
   <p>The remaining fields consist of name-value pairs, with the name
   part separated from the value part by a colon and a space (bytes
   0x3A 0x20). Of these, several are interesting:</p>
@@ -75212,41 +75243,43 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
 
    <dd>
 
     <p>The value gives the hostname that the client intended to use
     when opening the Web Socket. It would be of interest in particular
     to virtual hosting environments, where one server might serve
     multiple hosts, and might therefore want to return different
     data.</p>
 
     <p>The right host has to be output as part of the <span>URL</span>
-    given on the <code title="">WebSocket-Location</code> line of the
-    handshake described above, to verify that the server knows that it
-    is really representing that host.</p>
+    given on the <code
+    title="http-websocket-location">WebSocket-Location</code> line of
+    the handshake described above, to verify that the server knows
+    that it is really representing that host.</p>
 
    </dd>
 
    <dt>Origin (bytes 4F 72 69 67 69 6E)</dt> <!-- http-origin -->
 
    <dd>
 
     <p>The value gives the scheme, hostname, and port (if it's not the
     default port for the given scheme) of the page that asked the
     client to open the Web Socket. It would be interesting if the
     server's operator had deals with operators of other sites, since
     the server could then decide how to respond (or indeed,
     <em>whether</em> to respond) based on which site was requesting a
     connection.</p>
 
     <p>If the server supports connections from more than one origin,
     then the server should echo the value of this field in the initial
-    handshake, on the <code title="">WebSocket-Origin</code> line.</p>
+    handshake, on the <code
+    title="http-websocket-origin">WebSocket-Origin</code> line.</p>
 
    </dd>
 
    <dt>Other fields</dt>
 
    <dd>
 
     <p>Other fields can be used, such as "<code
     title="">Cookie</code>" or "<code>Authorization</code>", for
     authentication purposes.</p>
@@ -75367,21 +75400,21 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
   <p>If at any time a server is faced with data that it does not
   understand, or that violates some criteria by which the server
   determines safety of input, or when the server sees a handshake that
   does not correspond to the values the server is expecting
   (e.g. incorrect path or origin), the server should just
   disconnect. It is always safe to disconnect.</p>
 
 
   <h5>IANA considerations</h5>
 
-  <h6>Registration of ws: scheme</h6>
+  <h6>Registration of <code title="">ws:</code> scheme</h6>
 
   <p>A <code title="">ws:</code> URL identifies a Web Socket server
   and resource name.</p>
 
   <dl>
 
    <dt>URI scheme name.</dt>
    <dd>ws</dd>
 
    <dt>Status.</dt>
@@ -75434,21 +75467,21 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
 
    <dt>Author/Change controller.</dt>
    <dd>Ian Hickson &lt;ian@hixie.ch></dd>
 
    <dt>References.</dt>
    <dd>This document.</dd>
 
   </dl>
 
 
-  <h6>Registration of wss: scheme</h6>
+  <h6>Registration of <code title="">wss:</code> scheme</h6>
 
   <p>A <code title="">wss:</code> URL identifies a Web Socket server
   and resource name, and indicates that traffic over that connection
   is to be encrypted.</p>
 
   <dl>
 
    <dt>URI scheme name.</dt>
    <dd>wss</dd>
 
@@ -75502,39 +75535,114 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
 
    <dt>Author/Change controller.</dt>
    <dd>Ian Hickson &lt;ian@hixie.ch></dd>
 
    <dt>References.</dt>
    <dd>This document.</dd>
 
   </dl>
 
 
-  <h6>Registration of the "WebSocket" HTTP Upgrade keyword</h6>
+  <h6>Registration of the "<code title="">WebSocket</code>" HTTP Upgrade keyword</h6>
 
   <dl>
 
    <dt>Name of token.</dt>
    <dd>WebSocket</dd>
 
    <dt>Author/Change controller.</dt>
    <dd>Ian Hickson &lt;ian@hixie.ch></dd>
 
    <dt>Contact.</dt>
    <dd>Ian Hickson &lt;ian@hixie.ch></dd>
 
    <dt>References.</dt>
    <dd>This document.</dd>
 
   </dl>
 
 
+
+  <h6><dfn title="http-websocket-origin"><code>WebSocket-Origin</code></dfn></h6>
+
+  <p>This section describes a header field for registration in the
+  Permanent Message Header Field Registry.  <a
+  href="#refsRFC3864">[RFC3864]</a></p>
+
+  <dl>
+   <dt>Header field name</dt>
+   <dd>WebSocket-Origin</dd>
+   <dt>Applicable protocol</dt>
+   <dd>http</dd>
+   <dt>Status</dt>
+   <dd>reserved; do not use outside WebSocket handshake</dd>
+   <dt>Author/Change controller</dt>
+   <dd>IETF</dd>
+   <dt>Specification document(s)</dt>
+   <dd>
+    This document is the relevant specification.
+   </dd>
+   <dt>Related information</dt>
+   <dd>None.</dd>   
+  </dl>
+
+
+  <h6><dfn title="http-websocket-protocol"><code>WebSocket-Protocol</code></dfn></h6>
+
+  <p>This section describes a header field for registration in the
+  Permanent Message Header Field Registry.  <a
+  href="#refsRFC3864">[RFC3864]</a></p>
+
+  <dl>
+   <dt>Header field name</dt>
+   <dd>WebSocket-Protocol</dd>
+   <dt>Applicable protocol</dt>
+   <dd>http</dd>
+   <dt>Status</dt>
+   <dd>reserved; do not use outside WebSocket handshake</dd>
+   <dt>Author/Change controller</dt>
+   <dd>IETF</dd>
+   <dt>Specification document(s)</dt>
+   <dd>
+    This document is the relevant specification.
+   </dd>
+   <dt>Related information</dt>
+   <dd>None.</dd>   
+  </dl>
+
+
+  <h6><dfn title="http-websocket-location"><code>WebSocket-Location</code></dfn></h6>
+
+  <p>This section describes a header field for registration in the
+  Permanent Message Header Field Registry.  <a
+  href="#refsRFC3864">[RFC3864]</a></p>
+
+  <dl>
+   <dt>Header field name</dt>
+   <dd>WebSocket-Location</dd>
+   <dt>Applicable protocol</dt>
+   <dd>http</dd>
+   <dt>Status</dt>
+   <dd>reserved; do not use outside WebSocket handshake</dd>
+   <dt>Author/Change controller</dt>
+   <dd>IETF</dd>
+   <dt>Specification document(s)</dt>
+   <dd>
+    This document is the relevant specification.
+   </dd>
+   <dt>Related information</dt>
+   <dd>None.</dd>   
+  </dl>
+
+
+
+
   <h5>Using the Web Socket protocol from other specifications</h5>
 
   <p>The Web Socket protocol is intended to be used by another
   specification to provide a generic mechanism for dynamic
   author-defined content, e.g. in a specification defining a scripted
   API.</p>
 
   <p>Such a specification first needs to "<span>establish a Web Socket
   connection</span>", providing that algorithm with:</p>
 
@@ -90083,25 +90191,25 @@ interface <span>HTMLDocument</span> {
   for its presence first. <a href="#refsECMA262">[ECMA262]</a></p>
 
   </div>
 
 
 
   <h2 class="no-num">IANA considerations</h2>
 
   <!-- http://www.w3.org/2002/06/registering-mediatype.html -->
 
+  <h3><dfn><code>text/html</code></dfn></h3>
+
   <p>This registration is for community review and will be submitted
   to the IESG for review, approval, and registration with IANA.</p>
 
-  <h3><dfn><code>text/html</code></dfn></h3>
-
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type text/html
   -->
 
   <!--
    Obsoletes:
    http://www.ietf.org/rfc/rfc2854
 
    Include a request to retire RFC 2854 persuant to section 6.4 of RFC 2026.
@@ -90205,20 +90313,23 @@ interface <span>HTMLDocument</span> {
    <dt>Change controller:</dt>
    <dd>W3C and WHATWG</dd>
   </dl>
 
   <p>Fragment identifiers used with <code>text/html</code> resources
   refer to <span>the indicated part of the document</span>.</p>
 
 
   <h3><dfn><code>application/xhtml+xml</code></dfn></h3>
 
+  <p>This registration is for community review and will be submitted
+  to the IESG for review, approval, and registration with IANA.</p>
+
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type application/xhtml+xml
   -->
 
   <!--
    Obsoletes:
    http://www.ietf.org/rfc/rfc3236.txt
   -->
 
@@ -90273,20 +90384,23 @@ interface <span>HTMLDocument</span> {
    <dd>W3C and WHATWG</dd>
   </dl>
 
   <p>Fragment identifiers used with <code>application/xhtml+xml</code>
   resources have the same semantics as with any <span>XML MIME
   type</span>. <a href="#refsRFC3023">[RFC3023]</a></p>
 
 
   <h3><dfn><code>text/cache-manifest</code></dfn></h3>
 
+  <p>This registration is for community review and will be submitted
+  to the IESG for review, approval, and registration with IANA.</p>
+
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type text/cache-manifest
   -->
 
   <dl>
    <dt>Type name:</dt>
    <dd>text</dd>
    <dt>Subtype name:</dt>
    <dd>cache-manifest</dd>
@@ -90345,20 +90459,23 @@ interface <span>HTMLDocument</span> {
    <dt>Change controller:</dt>
    <dd>W3C and WHATWG</dd>
   </dl>
 
   <p>Fragment identifiers have no meaning with
   <code>text/cache-manifest</code> resources.</p>
 
 
   <h3><dfn><code>text/ping</code></dfn></h3>
 
+  <p>This registration is for community review and will be submitted
+  to the IESG for review, approval, and registration with IANA.</p>
+
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type text/ping
   -->
 
   <dl>
    <dt>Type name:</dt>
    <dd>text</dd>
    <dt>Subtype name:</dt>
    <dd>ping</dd>
@@ -90411,20 +90528,23 @@ interface <span>HTMLDocument</span> {
    <dt>Change controller:</dt>
    <dd>W3C and WHATWG</dd>
   </dl>
 
   <p>Fragment identifiers have no meaning with
   <code>text/ping</code> resources.</p>
 
 
   <h3><dfn><code>application/microdata+json</code></dfn></h3>
 
+  <p>This registration is for community review and will be submitted
+  to the IESG for review, approval, and registration with IANA.</p>
+
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type application/microdata+json
   -->
 
   <dl>
    <dt>Type name:</dt>
    <dd>application</dd>
    <dt>Subtype name:</dt>
    <dd>microdata+json</dd>
@@ -90480,20 +90600,68 @@ interface <span>HTMLDocument</span> {
    <dt>Change controller:</dt>
    <dd>W3C and WHATWG</dd>
   </dl>
 
   <p>Fragment identifiers used with
   <code>application/microdata+json</code> resources have the same
   semantics as when used with <code>application/json</code>. <a
   href="#refsJSON">[JSON]</a></p>
 
 
+  <h6><dfn title="http-ping-from"><code>Ping-From</code></dfn></h6>
+
+  <p>This section describes a header field for registration in the
+  Permanent Message Header Field Registry.  <a
+  href="#refsRFC3864">[RFC3864]</a></p>
+
+  <dl>
+   <dt>Header field name</dt>
+   <dd>Ping-From</dd>
+   <dt>Applicable protocol</dt>
+   <dd>http</dd>
+   <dt>Status</dt>
+   <dd>standard</dd>
+   <dt>Author/Change controller</dt>
+   <dd>W3C and WHATWG</dd>
+   <dt>Specification document(s)</dt>
+   <dd>
+    This document is the relevant specification.
+   </dd>
+   <dt>Related information</dt>
+   <dd>None.</dd>   
+  </dl>
+
+
+  <h6><dfn title="http-ping-to"><code>Ping-To</code></dfn></h6>
+
+  <p>This section describes a header field for registration in the
+  Permanent Message Header Field Registry.  <a
+  href="#refsRFC3864">[RFC3864]</a></p>
+
+  <dl>
+   <dt>Header field name</dt>
+   <dd>Ping-To</dd>
+   <dt>Applicable protocol</dt>
+   <dd>http</dd>
+   <dt>Status</dt>
+   <dd>standard</dd>
+   <dt>Author/Change controller</dt>
+   <dd>W3C and WHATWG</dd>
+   <dt>Specification document(s)</dt>
+   <dd>
+    This document is the relevant specification.
+   </dd>
+   <dt>Related information</dt>
+   <dd>None.</dd>   
+  </dl>
+
+
 
   <h2 class="no-num">Index</h2>
 
   <p><i>This section is non-normative.</i></p>
 
   <table>
    <caption>List of elements</caption>
    <thead>
     <tr>
      <th> Element
@@ -91103,20 +91271,26 @@ interface <span>HTMLDocument</span> {
    <dt id="refsRFC3490">[RFC3490]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3490.txt">Internationalizing
    Domain Names in Applications (IDNA)</a></cite>, P. Faltstrom, P. Hoffman, A.
    Costello. IETF, March 2003.</dd>
 
    <dt id="refsRFC3548">[RFC3548]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3548.txt">The Base16, Base32,
    and Base64 Data Encodings</a></cite>, S. Josefsson. IETF, July
    2003.</dd>
 
+   <dt id="refsRFC3864">[RFC3864]</dt>
+   <dd><cite><a
+   href="http://www.ietf.org/rfc/rfc3864.txt">Registration Procedures
+   for Message Header Fields</a></cite>, G. Klyne, M. Nottingham,
+   J. Mogul. IETF, September 2004.</dd>
+
    <dt id="refsRFC3986">[RFC3986]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3986.txt">Uniform Resource
    Identifier (URI): Generic Syntax</a></cite>, T. Berners-Lee, R. Fielding, L.
    Masinter. IETF, January 2005.</dd>
 
    <dt id="refsRFC3987">[RFC3987]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized
    Resource Identifiers (IRIs)</a></cite>, M. D&uuml;rst, M. Suignard. IETF, January
    2005.</dd>
 

|