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.

As far as I am aware, HTTP has no such UI requirement for initial  
requests, only for redirects. It does have some non-normative advice  
on the non-redirect case but no actual requirements for UAs.

> Is this a correct understanding? The question is directed towards the
> people that have been arguing for @ping to be removed from HTML5.
>
> 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?

I don't think that argument was ever grounded in what the HTTP spec  
actually requires, but perhaps its proponents could clarify that  
position.

> I realize that the other objection in the change proposal would
> remain. I.e. the argument that sites are unlikely to want to rely on
> the feature.

Indeed. (Though future information, such as deployment on sites, could  
lead us to revisit that argument.)

Regards,
Maciej

Received on Wednesday, 24 February 2010 03:48:37 UTC