On Fri, 13 Oct 2006 10:36:22 +0200, sureau denis [EMAIL PROTECTED]
wrote:
There is a lot of such histories around, and they
are far more complete that this one. Seems not really
useful in a specification.
I don't really recall anyone requesting it. I think it was originally in
the
On Fri, 13 Oct 2006 11:31:37 +0200, Gorm Haug Eriksen [EMAIL PROTECTED]
wrote:
I think Allamarajus issue is valid. Having closely tied browser
specifications that are not implementable in the browser is questionable.
What do you mean with this?
We should discuss further if the
Anne van Kesteren [EMAIL PROTECTED]
On Fri, 13 Oct 2006 11:31:37 +0200, Gorm Haug Eriksen [EMAIL PROTECTED]
wrote:
I think Allamarajus issue is valid. Having closely tied browser
specifications that are not implementable in the browser is questionable.
What do you mean with this?
It's a
On Oct 13, 2006, at 01:55, Anne van Kesteren wrote:
I actually agree with Mark (earlier on) and Subbu. It's not the job
of the XMLHttpRequest specification to decide which methods have to
be supported. Whatever the implementation cost actually is.
And you guarantee interoperability how?
Interoperability between?On 10/13/06, Robin Berjon [EMAIL PROTECTED] wrote:
On Oct 13, 2006, at 01:55, Anne van Kesteren wrote: I actually agree with Mark (earlier on) and Subbu. It's not the job of the XMLHttpRequest specification to decide which methods have to be supported. Whatever the
The current draft says that If the url parameter doesn't match the syntax defined in
section 3.2.2 of [RFC2616] a
SYNTAX_ERR must be raisedSec 3.2.2 on RFC2616 refers to the URI syntax of the http scheme. Since this does not include the https scheme, should another RFC be quoted here?
There is a lot of architecture in the clipboard.
I think it is important that the WebAPI clipboard is very web
architecture compatible.
Desktop clipboards, like HTTP, have concepts of type negotiation.
It would logical to make the clipboard type in WebAPI carry content-type
[and later
