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

On Mon, 24 Nov 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > > No, that wouldn't help, as it's supposed to *replace* those, not 
> > > extend them.
> > 
> > Then I don't understand what you want.
> 
> 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?

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 note that there are browsers that do not display the link target 
> > > itself in the status bar)
> > 
> > Indeed, different browsers have different user interfaces, and so 
> > different solutions make sense for different browsers. This is why the 
> > specification doesn't say anything about UI.
> 
> 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.

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


> > I don't see how bloomberg.com could do the link notification. It 
> > certainly doesn't seem like something that a publisher would be 
> > interested in doing.
> 
> Of course the site hosting the ad also has interest in tracking the 
> link, for instance, to keep a record of clicks for comparison.

Yes, and ping="" allows for multiple sites to be notified if they desire. 
My point is just that one of our requirements is that the ad publisher and 
the click tracker not be forced to be the same host, and that there are no 
solutions to that right now that have a good user experience.


> > > So, avoiding the term "consensus"... This feature is much more 
> > > controversial than many other new features.
> > 
> > Oh my, no, not at all. We've had far, far more complaints about, say, 
> > headers="", or <img alt="">, or the video codecs issue. (The latter in 
> > particular has triggered orders of magnitude more feedback than 
> > ping="" ever has. We probably got more new subscribers out of the 
> > codecs debacle than we've ever received e-mails total on ping="".)
> 
> "...than many other new features...".
> 
> I didn't say there are other things that are more controversial.
> 
> Also, there's a difference between a new feature being added as opposed 
> to an HTML4 feature being changed (you couldn't take out the HTML4 
> feature, all you could do is take out the change from HTML4).

A lot of the controversy about headers="" was that we had in fact not 
included it at all, which some people interpreted as removal. 


> 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.


> 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.


> 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.


> > > This also was discussed before; you *could* use a new method, and 
> > > you do not need the HTTPbis working group for that. You should try 
> > > to get IETF approval though.
> > 
> > Since you are the one who believes that using POST is a problem, and 
> > since you are apparently better versed in these matters than me, could 
> > you please do the honours? If we had a new method, I would be happy to 
> > use it.
> 
> I do believe that we shouldn't spend our time working on this, so, no, I 
> won't do 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.


> > > Lots of suggestions have been made already, such as
> > > 
> > > - not doing it at all,
> > 
> > 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.


> > > - 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?


> > > I would recommend to put these proposals as examples of potential 
> > > implementations into the spec, so people can review them and comment 
> > > on them.
> > 
> > As noted above, the specification is not an appropriate place for user 
> > interface discussions.
> 
> In general, yes. In this case however, this affects privacy, and the 
> spec already makes a requirement on the UI.

Requirement that there _be_ a UI is very different than discussing what 
that UI will be like. But I've added a paragraph about this.


> > > Furthermore, while we're at it:
> > > 
> > > "For URLs that are HTTP URLs, the requests must be performed by 
> > > fetching the specified URLs using the POST method, with an empty 
> > > entity body in the request...."
> > > 
> > > This text is very misleading. You don't "fetch" URLs.
> > 
> > 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.



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?)

 * 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).

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

Anything else?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 24 November 2008 22:42:42 UTC