Changeset 11133 for dotorg

Show
Ignore:
Timestamp:
08/12/2008 10:04:34 PM (4 months ago)
Author:
dave
Message:

regenerated html.

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • dotorg/trunk/html/beps/bep_0022.html

    r11131 r11133  
    3939<tr class="field"><th class="field-name">Title:</th><td class="field-body">BitTorrent Local Tracker Discovery Protocol</td> 
    4040</tr> 
    41 <tr class="field"><th class="field-name">Version:</th><td class="field-body">11129</td> 
    42 </tr> 
    43 <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://bittorrent.org/trac/browser/dotorg/trunk/html/beps/bep_0022.rst">2008-08-12 21:23:42 -0700 (Tue, 12 Aug 2008)</a></td> 
     41<tr class="field"><th class="field-name">Version:</th><td class="field-body">11132</td> 
     42</tr> 
     43<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://bittorrent.org/trac/browser/dotorg/trunk/html/beps/bep_0022.rst">2008-08-12 22:03:39 -0700 (Tue, 12 Aug 2008)</a></td> 
    4444</tr> 
    4545<tr class="field"><th class="field-name">Author:</th><td class="field-body">David Harrison &lt;dave&#32;&#97;t&#32;bittorrent.com&gt;, Stanislav Shalunov &lt;shalunov&#32;&#97;t&#32;bittorrent.com&gt;, Greg Hazel &lt;greg&#32;&#97;t&#32;bittorrent.com&gt;</td> 
    … …  
    140140<p>The domain name returned from the reverse DNS lookup is specific to 
    141141the querying host.  In the naive implementation in DNS, there would be 
    142 one SRV resource record for every querying host.  A natural but 
    143 incorrect solution is to use a wildcard of the form:</p> 
     142one SRV resource record for every querying host.  This would work but 
     143is burdensome.  A natural, seemingly less burdensome, but incorrect 
     144solution is to use a wildcard of the form:</p> 
    144145<pre class="literal-block"> 
    145146*.pacbell.net 
    … …  
    147148<p>If wildcards are implemented according to the algorithm in section 
    1481494.3.2 in <a class="footnote-reference" href="#rfc-1034" id="id5">[4]</a> then all subdomains of pacbell.net that do not 
    149 have an exact label match will match the wildcard.  Thus,</p> 
     150have an exact label match will match the wildcard.  Thus unless there 
     151is an exact match then queries for</p> 
     152<pre class="literal-block"> 
     153_bittorrent-tracker._tcp.adsl-69-107-0-14.dsl.pltn13.pacbell.net 
     154</pre> 
     155<p>and</p> 
    150156<pre class="literal-block"> 
    151157_jabber._tcp.pacbell.net 
    152 </pre> 
    153 <p>and</p> 
    154 <pre class="literal-block"> 
    155 _bittorrent-tracker._tcp.pacbell.net 
    156158</pre> 
    157159<p>both match *.pacbell.net and all SRV resource records with owner 
    … …  
    165167_bittorrent-tracker._tcp.*.pacbell.net 
    166168</pre> 
    167 <p>However, section 4.3.3 in <a class="footnote-reference" href="#rfc-1034" id="id6">[4]</a> specifies that wildcards only 
    168 appear as the first label in a domain name.  This restriction was 
    169 lifted in <a class="footnote-reference" href="#rfc-4592" id="id7">[7]</a>, but not with semantics applicable to our use 
    170 case.  An asterisk not at the beginning of a domain name is not 
    171 treated like a wildcard.  Only a lookup for the exact domain name</p> 
     169<p>Section 4.3.3 in <a class="footnote-reference" href="#rfc-1034" id="id6">[4]</a> specifies that wildcards only appear as 
     170the first label in a domain name.  This restriction was lifted in 
     171<a class="footnote-reference" href="#rfc-4592" id="id7">[7]</a>, but not with semantics applicable to our use case.  An 
     172asterisk not at the beginning of a domain name is not treated like a 
     173wildcard.  Only a lookup for the exact domain name</p> 
    172174<pre class="literal-block"> 
    173175_bittorrent-tracker._tcp.*.pacbell.net