Re: a/@ping discussion (ISSUE-1 and ISSUE-2), was: An HTML language specification vs. a browser specification

Ian Hickson wrote:
>> Roy stated that ping should be in a separate proposal:
>>
>> RF> I don't care how long ping has been under consideration by WHATWG
>> RF> mailing lists, nor do I care how many fanboys have thought in the past
>> RF> that it is worth implementing. It represents a change to HTML (a harmful
>> RF> one at that). Place it on the block and let it fight for itself in terms
>> RF> of implementation. It should be a separate proposal until it has been
>> RF> successfully implemented by two independent implementations. Likewise
>> RF> for all of the other new additions.
>>
>> I think it's clear that we he meant was "separate from the HTML5 spec as 
>> of today".
> 
> I don't understand why "ping" is special here. Surely this is what we 
> should do for everything that's new in HTML5? And if so, given that pretty 
> much the entire spec is new, why isn't HTML5 itself the proposal?

The spec may be new, but most of what it describes is not.

> Maybe you are not used to the strict application of the rule that we must 
> have two complete and bug-free implementations (with evidence that the 
> implementations are used) to keep the feature beyond CR. We will be 
> cutting big parts of the spec out; if ping="" doesn't prove itself, it 
> _will_ be cut, just like anything else.

I personally would like things to be cut out earlier.

>> Not displaying the target of a link is considered a security issue 
>> nowadays. I hope that at some point some of the specs we're working on 
>> will have a Security Considerations section pointing that out.
>>
>> The point I was trying to make was that one of the "four big" UAs 
>> doesn't even get *this* right, so I have my doubts that the situation 
>> will be any better with a/@ping.
> 
> I tried all my browsers and couldn't find one that didn't show the URL 
> when hovering over a link, so I'm not sure what you're referring to here. 
> If we get as good interop with ping="" as with <a href="">, I'll be happy.

At least on Windows XP, Safari does not display the link target anywhere.

> Anyway I've added an example paragraph to the spec mentioning one possible 
> way of showing the ping URLs.

Thanks, that helps.

> ...
>> Do you have evidence of proxies not respecting Cache-Control: no-cache? 
>> And, if yes, would it affect the accuracy sufficiently?
> 
> Proxying behaviour with GET is unpredictable enough to be a problem, yes. 
> I don't have any specifics I can point to in public, though.
> ...

It would be helpful to have that information.

>> Furthermore: preventing fraud for click tracking is a hard problem. 
>> Using POST instead of GET won't help anyway with respect to this.
> 
> It doesn't solve the problem, but it helps.

How?

>> The problem of people visiting the target URL can be dealt with in 
>> several ways; for instance by having an additional request header (which 
>> you happen to have already).
> 
> Having a different method is even better.

Yes, I happen to agree with that.

>> If you want to do it, I'll be happy to assist with the process. 
>> Basically, the best way is to describe the method (syntax + semantics) 
>> in a separate document, and get IESG approval for it.
> 
> I don't understand how the semantics differ from POST, so I'm really the 
> wrong person to write that document.  
> 
> I'm happy to use a method if one is available. If you're not willing to do 
> the work to set that up, then your complaints about using the wrong method 
> lose a lot of credibility and really seem to appear more like 
> obstructionism than constructive criticism.

On the other hand, I do not understand how the semantics differ from 
GET, so I'm not the right person to write it either.

>>> Hardly an improvement, since it doesn't address any of the use cases.
>> There is no agreement that this use case is something HTML5 needs to 
>> solve.
> 
> There is agreement, just not with you.

Then please let the chairs test the level of agreement.

>>>> - when using POST, at least make the message self-descriptive by 
>>>> using a body + well-defined MIME type, or
>>> I've changed the spec to include an entity body with a new MIME type.
>> That's a step into the right direction. It would be better if the 
>> payload actually was in the body instead of new headers.
> 
> Why?

Because that's what the payload is for, and it avoids polluting the 
header registry with headers that are tied to a single specific use case.

> ...
>>> The word "fetch" is a term defined by HTML5 (hence why it is 
>>> hyperlinked in that sentence).
>> I understand that, but that doesn't change the fact that it's 
>> misleading.
> 
> I don't understand how it is misleading.
> ...

The only thing I could do at this point is repeat what I already said.

> As far as I can tell, your objections to ping="" are as follows:
> 
>  * You don't agree that we should improve the user experience around 
>    click-tracking. (Why not?)

Nope.

I don't agree that the solution as specified will be reliable enough so 
that it actually gets used; thus I'm opposed to including it into a 
standards project that is already complicated enough.

I'm also concerned that UAs may implement the protocol part and neglect 
the UI part (which essentially is what almost happened in Firefox 3).

>  * You think that using POST is a security problem (despite evidence that 
>    it introduces no _new_ security problems), and would rather we use GET 
>    or HEAD (implying that we should ignore the feedback that these are not 
>    acceptable).

I think that using POST *can* produce new security problems, while 
GET/HEAD wouldn't, and that GET/HEAD would just work fine. I also 
believe that issuing an unsafe HTTP request in the context of page 
navigation is in conflict with the web architecture.

>  * You think the Ping-To and Ping-From headers should be in the body of 
>    the ping. (Why?)

See above.

> Anything else?

No, I think that's it.

BR, Julian

Received on Monday, 24 November 2008 23:00:37 UTC