Re: CfC: Adopt ISSUE-1 PINGUI / ISSUE-2 PINGPOST Change Proposal to remove @ping from HTML5

On Feb 23, 2010, at 7:27 PM, Jonas Sicking wrote:

> On Tue, Feb 23, 2010 at 6:38 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> 
>> The original Change Proposal for these two issues proposed removing the <a
>> ping> attribute and associated hyperlink auditing feature. Although we had a
>> counter-proposal, we now seem to have consensus that it is ok to drop this
>> feature from HTML5. Thus, we should adopt the Change Proposal to remove the
>> feature. The feature could still be proposed again for a later issue of
>> HTML, or the issue could be re-raised if new information is provided (such
>> as implementation experience  or server-side deployment experience.)
>> 
>> If there are no objections, these two issues will be closed on March 2,
>> 2010.
>> 
>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-001
>> http://www.w3.org/html/wg/tracker/issues/1
>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-002
>> http://www.w3.org/html/wg/tracker/issues/2
> 
> My understanding is that one of the objections to keeping @ping in the
> spec is that HTTP requires that POST requests are not made by the UA
> unless this has been made clear to the user that this is happening.
> I.e. that the HTTP spec requires some type of UI. And since @ping will
> use a UI very similar to "ping less" links, this would then be counter
> to the requirements in the HTTP spec.
> 
> Is this a correct understanding? The question is directed towards the
> people that have been arguing for @ping to be removed from HTML5.

No.  It is a requirement on all Web architecture, and specifically
on browsers, that the user agent portray an unsafe method invocation
differently than a safe method invocation.  HTTP/1.1 only refers to
what was commonly known at the time.

   9.1.1 Safe Methods

   Implementors should be aware that the software represents the user
   in their interactions over the Internet, and should be careful to
   allow the user to be aware of any actions they might take which may
   have an unexpected significance to themselves or others.

   In particular, the convention has been established that the GET and
   HEAD methods SHOULD NOT have the significance of taking an action
   other than retrieval. These methods ought to be considered "safe".
   This allows user agents to represent other methods, such as POST,
   PUT and DELETE, in a special way, so that the user is made aware of
   the fact that a possibly unsafe action is being requested.

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request;
   in fact, some dynamic resources consider that a feature. The
   important distinction here is that the user did not request the
   side-effects, so therefore cannot be held accountable for them.

The requirement is from TimBL's original axioms.  The closest I can
come to describing them is

  http://www.w3.org/2001/tag/doc/whenToUseGet.html
  http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction

though those documents don't state the obvious corollary that
browsers must not portray unsafe actions in the same way that
they portray safe actions (links).

The requirement is not explicit in HTTP because it is a browser
UI issue.  However, both HTML and HTTP were designed to avoid
situations where an unsafe method is used as a result of
selecting a simple link.  This was supposed to appear in the
"browser conformance" specification that W3C never developed,
for which the current HTML5 draft would be a candidate.

> If a future version of HTTP, such as the in progress HTTPbis, was
> released and removed this UI requirement, would that remove that
> specific objection?

No, and in any case that will never happen.  Generally speaking,
asking the IETF to introduce yet another fool-the-user spoof in
browsers is a non-starter.

Think about it folks.  These principles, axioms, constraints, and
requirements are all there because people learned early on about
the nature of the Internet as an unsafe place.  The fact that a
few browsers have other unsafe features does not justify adding
another one to the standard, especially given that it hasn't even
been implemented yet by browsers [who are, naturally, quite shy
about introducing features that will result in new privacy and
security concerns].

....Roy

Received on Wednesday, 24 February 2010 08:07:38 UTC