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

Ian Hickson wrote:
>> The spec may be new, but most of what it describes is not.
> 
> I beg to differ. I can't really think of anything in HTML4 that hasn't had 
> new requirements added in HTML5 (usually to remove ambiguities, define 
> processing in more detail, or define error handling).

Yes. But that's what I meant by "new".

> ...
> I agree that feedback should be public. However, I'm not going to ignore 
> private feedback.
> ...

Is there any reason why you can't forward this feedback in some kind of 
anonymized form?


>>>> 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?
> 
> It makes it less likely that the link will be followed by people who don't 
> realise it's a ping. For example, a tool that scans an HTML file for URLs 
> and fetches them all to check for broken links would cause problems if we 
> used GET or HEAD, but would be fine if we had a different method.

That tools wouldn't send the payload specified in the spec, so how would 
that matter?

> ...
>> Then please let the chairs test the level of agreement.
> 
> What have I done to prevent the chairs from testing agreement?

Nothing.

> ...
>> 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.
> 
> Ok. 
> 
> I've received feedback from pretty big click-tracking groups saying they 
> plan to use it as is, so implementation feedback seems to support keeping 
> it in the draft.
> 
> Do you have any proposals for making it more reliable?

No.

>> 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).
> 
> Since, as you pointed out, one of the reasons for disabling it in FF3 was 
> lack of UI, that seems like an unfounded concern.

Well, it *almost* happened once (and essentially didn't happen because a 
few people noticed early enough). So I would be surprised if it does 
happen in the future.

> ...
>> I think that using POST *can* produce new security problems, while 
>> GET/HEAD wouldn't,
> 
> Could you describe the new security problem? So far all you have described 
> are problems that already exist with forms.

It follows from the fact that POST can have write semantics while 
HEAD/GET doesn't.

>> and that GET/HEAD would just work fine.
> 
> I have received implementation feedback to the effect that they would not, 
> which is why we are not using them.

It would be nice to see that feedback in a public place.

> ...
>> 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.
> 
> That seems like a theoretical ("spec purity") concern. I've received 
> feedback from implementors to the effect that headers are more convenient 
> (e.g. they can be processed by Apache's log module more easily), so by our 
> "priority of constituencies" design principle, the right solution seems to 
> be to compromise on what we have now (a non-empty payload, but keeping the 
> data in the current headers).

For the record: that "design" principle seems to get abused again and 
again to support the "we'll do whatever seems to work" approach.

>>> Anything else?
>> No, I think that's it.
> 
> So in summary: 
> 
> * You don't agree that the solution as specified will be reliable enough 
>   so that it actually gets used - other feedback claims otherwise.

Feedback you haven't shown us. Also, contrary to feedback from others.

It would be nice if the parties interested in this feature would get 
together and work on this as a separate activity, instead of requiring 
*us* to discuss based on unpublished feedback.

> * You are concerned that UAs may implement the protocol part and neglect 
>   the UI part - implementators have specifically avoided doing this.

FF3 almost shipped with it without UI support; which I think is evidence 
that there's a danger.

> * You think that using POST *can* produce new security problems, while
>   GET/HEAD wouldn't - but haven't described these problems.

My concern is based on the semantics on POST, which is a big enough 
reason for me.

> * You think that GET/HEAD would just work fine - other feedback claims 
>   otherwise.

Again: feedback you aren't showing us.

> * You believe that issuing an unsafe HTTP request in the context of 
>   page navigation is in conflict with the web architecture - but are not 
>   willing to do the work to get a more suitable method that doesn't 
>   conflict with other feedback we've received, and our design principles 
>   say I must put practical implementation concerns above spec purity.

"These design principles are an attempt to capture consensus on design 
approach. They are pragmatic rules of thumb that must be balanced 
against each other, not absolutes. They are similar in spirit to the 
TAG's findings in Architecture of the World Wide Web, but specific to 
the deliverables of this group."

> * You think the Ping-To and Ping-From headers should be in the body
>   of the ping 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 - but other feedback has said that there are 
>   implementation reasons to prefer headers, and our design principles
>   say I must put practical implementation concerns above spec purity.

Again, this is the "whatever hack gets us there, no matter what the base 
specs say" approach.

I really think we need to have an iteration on the discussion of design 
principles.

BR, Julian

Received on Thursday, 27 November 2008 13:51:28 UTC