Skip to content
Browse files

Laurent Walter Groix comments

  • Loading branch information...
1 parent 137a382 commit 2e64f126de043e134d473a8cb53464535879a7e2 @julien51 julien51 committed May 2, 2012
Showing with 5 additions and 23 deletions.
  1. +3 −12 pubsubhubbub-core-0.4.html
  2. +2 −11 pubsubhubbub-core-0.4.xml
View
15 pubsubhubbub-core-0.4.html
@@ -146,7 +146,7 @@
<tr><td class="header">&nbsp;</td><td class="header">Google, Inc</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">M. Atkins</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Six Apart Ltd.</td></tr>
-<tr><td class="header">&nbsp;</td><td class="header">M. Genestoux</td></tr>
+<tr><td class="header">&nbsp;</td><td class="header">J. Genestoux</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Notifixious Inc.</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">February 5, 2012</td></tr>
</table></td></tr></table>
@@ -307,16 +307,7 @@
The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
of these urls, so the subscriber may subscribe to one or more of these.
- The former will point to the permanent URL for the resource being polled.
-</p>
-<p>Example:
-</p>
-<p>Hubs should provide an <a class='info' href='#RFC2818'>HTTPS<span> (</span><span class='info'>Rescorla, E., &ldquo;HTTP Over TLS,&rdquo; May&nbsp;2000.</span><span>)</span></a> [RFC2818] interface and publishers
- SHOULD use <a class='info' href='#RFC2616'>HTTPS<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;Hypertext Transfer Protocol -- HTTP/1.1,&rdquo; .</span><span>)</span></a> [RFC2616] in their hubs' discovery URLs.
- However, subscribers that do not support <a class='info' href='#RFC2818'>HTTPS<span> (</span><span class='info'>Rescorla, E., &ldquo;HTTP Over TLS,&rdquo; May&nbsp;2000.</span><span>)</span></a> [RFC2818] MAY
- try to fallback to <a class='info' href='#RFC2616'>HTTP<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;Hypertext Transfer Protocol -- HTTP/1.1,&rdquo; .</span><span>)</span></a> [RFC2616], which MAY work
- depending on the hub's policy. If the advertised url is <a class='info' href='#RFC2616'>HTTP<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;Hypertext Transfer Protocol -- HTTP/1.1,&rdquo; .</span><span>)</span></a> [RFC2616],
- subscriber MAY choose to try <a class='info' href='#RFC2818'>HTTPS<span> (</span><span class='info'>Rescorla, E., &ldquo;HTTP Over TLS,&rdquo; May&nbsp;2000.</span><span>)</span></a> [RFC2818] first.
+ The latter will point to the permanent URL for the resource being polled.
</p>
<p>In the absence of HTTP Link headers, subscribers MAY fall back to
other methods to discover the hub(s) and the canonical URI of the topic.
@@ -622,7 +613,7 @@
</p>
<p>The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
- response codes as failures; that means subscribers MUST not use HTTP
+ response codes as failures; that means subscribers MUST NOT use HTTP
redirects for moving subscriptions. The response body from the
subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
repeatedly until successful (up to some reasonable maximum over a
View
13 pubsubhubbub-core-0.4.xml
@@ -168,16 +168,7 @@
The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
of these urls, so the subscriber may subscribe to one or more of these.
- The former will point to the permanent URL for the resource being polled.</t>
-
- <t>Example:</t>
-
- <t>Hubs should provide an <xref target="RFC2818">HTTPS</xref> interface and publishers
- SHOULD use <xref target="RFC2616">HTTPS</xref> in their hubs' discovery URLs.
- However, subscribers that do not support <xref target="RFC2818">HTTPS</xref> MAY
- try to fallback to <xref target="RFC2616">HTTP</xref>, which MAY work
- depending on the hub's policy. If the advertised url is <xref target="RFC2616">HTTP</xref>,
- subscriber MAY choose to try <xref target="RFC2818">HTTPS</xref> first.</t>
+ The latter will point to the permanent URL for the resource being polled.</t>
<t>In the absence of HTTP Link headers, subscribers MAY fall back to
@@ -453,7 +444,7 @@
<t>The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
- response codes as failures; that means subscribers MUST not use HTTP
+ response codes as failures; that means subscribers MUST NOT use HTTP
redirects for moving subscriptions. The response body from the
subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
repeatedly until successful (up to some reasonable maximum over a

0 comments on commit 2e64f12

Please sign in to comment.
Something went wrong with that request. Please try again.