[html5] r4091 - [] (0) Add IANA considerations sections for HTTP headers.
whatwg at whatwg.org
whatwg at whatwg.org
Tue Oct 6 03:02:44 PDT 2009
Author: ianh
Date: 2009-10-06 03:02:42 -0700 (Tue, 06 Oct 2009)
New Revision: 4091
Modified:
index
source
Log:
[] (0) Add IANA considerations sections for HTTP headers.
Modified: index
===================================================================
--- index 2009-10-06 06:35:35 UTC (rev 4090)
+++ index 2009-10-06 10:02:42 UTC (rev 4091)
@@ -1041,7 +1041,10 @@
<li><a href=#application/xhtml+xml><span class=secno>12.2 </span><code>application/xhtml+xml</code></a></li>
<li><a href=#text/cache-manifest><span class=secno>12.3 </span><code>text/cache-manifest</code></a></li>
<li><a href=#text/ping><span class=secno>12.4 </span><code>text/ping</code></a></li>
- <li><a href=#application/microdata+json><span class=secno>12.5 </span><code>application/microdata+json</code></a></ol></li>
+ <li><a href=#application/microdata+json><span class=secno>12.5 </span><code>application/microdata+json</code></a>
+ <ol>
+ <li><a href=#ping-from><span class=secno>12.5.1 </span><code>Ping-From</code></a></li>
+ <li><a href=#ping-to><span class=secno>12.5.2 </span><code>Ping-To</code></a></ol></ol></li>
<li><a class=no-num href=#index>Index</a></li>
<li><a class=no-num href=#references>References</a></li>
<li><a class=no-num href=#acknowledgements>Acknowledgements</a></ol>
@@ -6901,10 +6904,10 @@
<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>
+ protocols used, e.g. from the value of the HTTP <code 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>
@@ -53314,9 +53317,9 @@
of the <code>Document</code> object containing the hyperlink being
audited and the ping URL have the <a href=#same-origin>same origin</a></dt>
- <dd>The request must include a <code title=http-ping-from>Ping-From</code> HTTP header with, as its
+ <dd>The request must include a <code title=http-ping-from><a href=#ping-from>Ping-From</a></code> HTTP header with, as its
value, the <a href="#the-document's-address" title="the document's address">address</a> of
- the document containing the hyperlink, and a <code title=http-ping-to>Ping-To</code> HTTP header with, as its value,
+ the document containing the hyperlink, and a <code title=http-ping-to><a href=#ping-to>Ping-To</a></code> HTTP header with, as its value,
the address of the <a href=#absolute-url>absolute URL</a> of the target of the
hyperlink. The request must not include a <code title=http-referer>Referer</code> (sic) HTTP header. <!-- because
otherwise it would look like a trustable same-origin POST --></dd>
@@ -53328,8 +53331,8 @@
<dd>The request must include a <code title="">Referer</code> (sic)
HTTP header [sic] with, as its value, the <a href="#the-document's-current-address" title="the
document's current address">current address</a> of the document
- containing the hyperlink, a <code title=http-ping-from>Ping-From</code> HTTP header with the same
- value, and a <code title=http-ping-to>Ping-To</code> HTTP header
+ containing the hyperlink, a <code title=http-ping-from><a href=#ping-from>Ping-From</a></code> HTTP header with the same
+ value, and a <code title=http-ping-to><a href=#ping-to>Ping-To</a></code> HTTP header
with, as its value, the address of the target of the
hyperlink.</dd>
@@ -53337,10 +53340,10 @@
containing the hyperlink being audited was retrieved over an
encrypted connection</dt>
- <dd>The request must include a <code title=http-ping-to>Ping-To</code> HTTP header with, as its value,
+ <dd>The request must include a <code title=http-ping-to><a href=#ping-to>Ping-To</a></code> HTTP header with, as its value,
the address of the target of the hyperlink. The request must
neither include a <code title="">Referer</code> (sic) HTTP header
- nor include a <code title=http-ping-from>Ping-From</code> HTTP
+ nor include a <code title=http-ping-from><a href=#ping-from>Ping-From</a></code> HTTP
header.</dd>
</dl><p class=note>To save bandwidth, implementors might also wish to
@@ -73191,11 +73194,11 @@
<!-- http://www.w3.org/2002/06/registering-mediatype.html -->
+ <h3 id=text/html><span class=secno>12.1 </span><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 id=text/html><span class=secno>12.1 </span><dfn><code>text/html</code></dfn></h3>
-
<!--
To: ietf-types at iana.org
Subject: Registration of media type text/html
@@ -73304,6 +73307,9 @@
<h3 id=application/xhtml+xml><span class=secno>12.2 </span><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 at iana.org
Subject: Registration of media type application/xhtml+xml
@@ -73366,6 +73372,9 @@
<h3 id=text/cache-manifest><span class=secno>12.3 </span><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 at iana.org
Subject: Registration of media type text/cache-manifest
@@ -73433,6 +73442,9 @@
<h3 id=text/ping><span class=secno>12.4 </span><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 at iana.org
Subject: Registration of media type text/ping
@@ -73493,6 +73505,9 @@
<h3 id=application/microdata+json><span class=secno>12.5 </span><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 at iana.org
Subject: Registration of media type application/microdata+json
@@ -73554,9 +73569,46 @@
semantics as when used with <code>application/json</code>. <a href=#refsJSON>[JSON]</a></p>
+ <h6 id=ping-from><span class=secno>12.5.1 </span><dfn title=http-ping-from><code>Ping-From</code></dfn></h6>
- <h2 class=no-num id=index>Index</h2>
+ <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 id=ping-to><span class=secno>12.5.2 </span><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 id=index>Index</h2>
+
<p><i>This section is non-normative.</i></p>
<table><caption>List of elements</caption>
@@ -74041,6 +74093,11 @@
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.
Modified: source
===================================================================
--- source 2009-10-06 06:35:35 UTC (rev 4090)
+++ source 2009-10-06 10:02:42 UTC (rev 4091)
@@ -6873,10 +6873,10 @@
<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>
@@ -73095,9 +73095,9 @@
<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
@@ -73494,15 +73494,16 @@
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
@@ -73608,11 +73609,11 @@
<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 at iana.org
Subject: Registration of media type text/event-stream
@@ -73690,6 +73691,30 @@
<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-->
@@ -74789,21 +74814,24 @@
<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>,
@@ -74812,7 +74840,7 @@
<dt>If the entry's name is "<code
- title="">websocket-location</code>"</dt>
+ title="http-websocket-location">websocket-location</code>"</dt>
<dd>
@@ -74827,7 +74855,7 @@
<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>,
@@ -74836,9 +74864,10 @@
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
@@ -75138,8 +75167,9 @@
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
@@ -75153,8 +75183,9 @@
</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>
@@ -75193,8 +75224,8 @@
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
@@ -75219,9 +75250,10 @@
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>
@@ -75239,7 +75271,8 @@
<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>
@@ -75374,7 +75407,7 @@
<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>
@@ -75441,7 +75474,7 @@
</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
@@ -75509,7 +75542,7 @@
</dl>
- <h6>Registration of the "WebSocket" HTTP Upgrade keyword</h6>
+ <h6>Registration of the "<code title="">WebSocket</code>" HTTP Upgrade keyword</h6>
<dl>
@@ -75528,6 +75561,81 @@
</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
@@ -90090,11 +90198,11 @@
<!-- 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 at iana.org
Subject: Registration of media type text/html
@@ -90212,6 +90320,9 @@
<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 at iana.org
Subject: Registration of media type application/xhtml+xml
@@ -90280,6 +90391,9 @@
<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 at iana.org
Subject: Registration of media type text/cache-manifest
@@ -90352,6 +90466,9 @@
<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 at iana.org
Subject: Registration of media type text/ping
@@ -90418,6 +90535,9 @@
<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 at iana.org
Subject: Registration of media type application/microdata+json
@@ -90487,7 +90607,55 @@
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>
@@ -91110,6 +91278,12 @@
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.
More information about the Commit-Watchers
mailing list