W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: TRACK, was: LC comments.

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 13 Jun 2008 15:22:30 -0400 (EDT)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org
Message-ID: <Pine.LNX.4.64.0806131518400.3291@ubzre.j3.bet>

On Fri, 13 Jun 2008, Julian Reschke wrote:

>> Or they have implemented something completely unrelated in their server 
>> that just happens to be called TRACE and are confused why they can't 
>> interact with it using XMLHttpRequest.
> Which would mean that a non-normative appendix telling the story about the 
> risk related to TRACE (and TRACK) would be helpful.


>> That line of reasoning would mean that we shouldn't put any security 
>> restrictions in the spec and then just tell UAs to deal. There are several 
>> downsides with that:
>> 1. Users would get annoyed when running into the restrictions that don't
>>    show up in the spec.
> Like PROPFIND not working (IE7), or silently rewritten to "GET" or "POST" 
> (Opera)?
> Yes, I do agree that explaining this is useful, I just don't see why it's 
> necessary to make it a normative requirement, and put it into the API 
> documentation.
> An appendix would be completely sufficient.

This is just another proof that the spec should have two section, one 
designed for authors, and one for implementation considerations.

I would add that it is entirely possible to reorganize the spec, even 
after CR if no normative changes are done. Making the spec more clear as a 
result of editorial work will vastly improve its quality, and ensure that 
targeted parties will find what they need easily, and not relying on their 
hands-on experience with different browser because the spec might be 
opaque to some.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Friday, 13 June 2008 19:23:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:09 UTC