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

Ian Hickson wrote:
 > ...
 >>> HTML5? Would it help if you consider HTML5 spec as it stands today 
to _be_ the separate proposal?
 >> Separate to what?
 >
 > Separate to the specifications it is intended to replace, namely, 
HTML4, XHTML 1.x, and DOM2 HTML.

No, that wouldn't help, as it's supposed to *replace* those, not extend 
them.

 > ...
 >> I would expect that for implementations to be consistent, there 
would need to be a proposal *somewhere* how to implement this particular 
aspect.
 >
 > I have discussed such interface proposals with several browser 
vendors. For example, to address the above requirement, at least three 
proposals have been made: appending the hostnames of the ping targets to 
the status bar, as in:
 >
 >   +--------------------------------------------------------------+
 >   | http://example.com/ (Notifying example.org)                //|
 >   +--------------------------------------------------------------+
 >
 > ...or using a special cursor with a tooltip, or appending an inline 
icon next to the link.
 > ...

(I note that there are browsers that do not display the link target 
itself in the status bar)

So, what has been the feedback on these proposals? Where did the 
discussion occur?


 >> Speaking of which: I can easily imagine that in certain countries, 
laws will require this feature to be turned off by default.
 >
 > If true, that would be yet another reason to keep it -- it would make 
complying with local laws easier.

Interesting point.

So let's assume for a second that national regulations (in a country 
with significant population) would force a vendor to ship with this 
feature disabled. Would it still be used for link tracking in practice?

 >> img/@src causes GET requests, while a/@ping causes POST requests.
 >
 > Ok, then use <form>. ping="" is as easy to trigger as a form submission.

Not with scripting disabled, right? (yes, I use the FF noscript extension).

 > ...
 >> This introduces an additional party (example.org) to the operation. 
Why is this needed?
 >
 > It's a common use case. The ad publisher, the ad provider (and click 
tracker) and the ad target are commonly three different companies.

Why can't the site hosting the document do the link notification?

 >> But volume of comments can be an indicator of whether something has 
consensus or not.
 >
 > Sure. Nobody claims that we have consensus on this feature (or, for 
that matter, any feature). What's the relevance of this?

Nice strategy :-) By saying nothing has consensus, and consensus isn't 
relevant, it's of course simple to argue that controversial stuff should 
stay in.

So, avoiding the term "consensus"... This feature is much more 
controversial than many other new features.

 >> Following a hyperlink needs to *stay* a safe operation.
 >>
 >> Link auditing itself (whether desirable or not) is a safe operation 
from the p.o.v. of the user, and this is what's relevant here.
 >>
 >>> A ping is non-idempotent, too, so we can't use GET.
 >> I think you misunderstand the concept of idempotence, which could be 
caused by RFC 2616 being misleading.
 >>
 >> See discussion in 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/27>.
 >
 > Well, what method would you propose? GET is unacceptable for a number 
of reasons, such as bad caching behavior with proxies. Not having the 
feature rather fails to address the use cases.

HEAD/GET would work when used with the proper Cache headers (and yes, 
this was discussed before).

 > Would the HTTP working group be willing to add a more appropriate method?

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.

 >> And yes, sites need to handle arbitrary requests anyway; if they 
don't, they are buggy. But that's not an excuse for adding a way to 
create POST requests by simply navigating a web site.
 >
 > We already have a way to create POST requests by simply navigating a 
Web site. This isn't adding anything new as far as that goes.

That is incorrect, unless you count "pressing buttons" as web site 
navigation.

 > ...
 >> To summarize:
 >>
 >> - it's not clear that it will be used
 >
 > A number of groups, including Google, have said they will use it.

In which case I'd propose:

- see that it gets implemented in at least one browser (Chrome comes to 
mind)

- *demonstrate* that it's going to be used with that browser

 >> - the way it's implemented over HTTP is problematic
 >
 > Suggestions on improving it are welcome. I'm trying to do the best I 
can given HTTP's limitations.

Lots of suggestions have been made already, such as

- not doing it at all,

- not doing it with HTTP (TimBl proposed UDP, if I recall correctly),

- use GET/HEAD,

- when using POST, at least make the message self-descriptive by using a 
body + well-defined MIME type, or

- use a different method.

 >> - there's no proposal for a UI that would comply with the 
requirements in the spec
 >
 > There are several such proposals.

I would recommend to put these proposals as examples of potential 
implementations into the spec, so people can review them and comment on 
them.

 >> So this is a very good example for a part of HTML5 that clearly is 
not stable
 >
 > It's as stable as most parts of the document. More stable than many.

I don't see it as "stable", it's definition has changed several times in 
the last two months (at least twice), and I personally expect it to be 
taken out before we're done.

 > ...
 >> and also could *easily* be specified separately.
 >
 > Not really; it's part of the vocabulary and directly affects link 
navigation, a pretty core part of HTML.

Now that's an interesting statement. Are you saying that the vocabulary 
*needs* to be defined in single place, even a truly optional attribute? 
Where does that leave us with respect to future extensibility?

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. Also, POST isn't a 
retrieval method, it operates on the specified URI. The result *can* be 
a response (which doesn't need to represent the resource in any way), 
plus, optionally, a pointer to a separate resource from which a 
representation than can be fetched (Location header + 3xx).

BR, Julian

Received on Sunday, 23 November 2008 11:20:20 UTC