On 13/12/2011, at 2:07 PM, Julian Reschke wrote: > On 2011-12-13 14:50, Cameron Heavon-Jones wrote: >>> Yes, but that's for the format. An Accept header of >>> >>> Accept: text/html >>> >>> doesn't tell the server *what* kind of HTML content you want (a status >>> message vs something that could be used as a next page in a user >>> interaction). >> >> I think that is quite definitely Out Of Scope. If there needs to be >> different content for the same format this should be a different URI. > > I disagree. If you need separate URIs to make this work, something is wrong.
It's not a question of 'getting it to work', it is a question of whether it is correct to assume that the same request should result in two different responses - that is wrong. unfortunately we're discussing specific implementations - a WebDAV server. This isn't even spec'd WebDAV behaviour, it's just what current servers are doing. There is no foundation to expect existing services to magically just start integrating with new clients. WebDAV servers are written for WebDAV clients, not HTML browser clients. Servers *CAN* be written to support both with content-negotation, it's just that they won't be setup like this in existing software. ** You will not be able to write a form which integrates with an existing WebDAV server and has all the behaviour you would _now_ expect *** > >> Working towards a concrete proposal is the aim here. Since the bug has been >> closed by the editor twice before i hesitate reopening it as it seems unable >> to progress through this channel. Also as a substantial piece of >> specification i think it will require full wg attention. >> >> That we're half way through last call is fine, this has been raised as an >> issue for a long time and it is in response to both wg and public feedback >> that it has progressed to its current state. While there is work still to >> do, it is limited in scope and i feel we are progressing well towards the >> solution. >> >> I don't think browser adoption will be an issue here, chrome had some >> support for PUT and DELETE however since its removal from the specification >> i'm unsure on any current implementation. As HTML is not due for >> recommendation for years it seems that browser vendors will still have >> plenty of time to implement re-speced features. >> >> Do you suggest any other means for this to progress other than escalation to >> an issue? >> ... > > We should try to come up with a complete proposal; as you see we aren't there > yet. Once we have that, we can either try to get it into HTML5 or HTML.next, > or write a separate delta spec. > > Best regards, Julian Yes we should definitely continue to work on a complete proposal, my concern is what happens to the bug in that time. I am not happy leaving the bug in a RESOLVED status. As you noted, time is moving on and i think it will progress the faster as an issue and with full attention. If the result of the issue is to punt it on to HTML.next then that is the outcome. Personally, however, this has been a core part of HTML5 since its inception and there is no reason for it to be excluded. The only reason i can see for not raising it as a issue at this time is due to the implied time restrictions on proposals. This is not a concrete enforcement however. Maybe we can add this information to the bug report and request that it remain open pending the development of the proposal? Isn't this the point of a tracker issue tho? Thanks, Cam
