- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 17 Feb 2007 18:00:54 +0100
- To: public-webapi@w3.org
Hi, see below some comments on the current draft. Best regards, Julian +++ 1. Introduction "First, the object is data transport agnostic - it supports any data format, including XML." Actually, it doesn't. As far as I can tell, it only supports text based formats and XML. There's no way to send or retrieve binary content. 1.2 Conformance "conforming implementation: A user agent that implements all interfaces described in this specification and follows all MUST-, REQUIRED- and SHALL-level of criteria in this specification." I found this a bit confusing, because MUST, REQUIRED and SHALL indeed are the same compliance level. I think it would be better to say: "conforming implementation: A user agent that implements all interfaces described in this specification and follows all MUST-level of criteria in this specification (note that this includes statements labeled "REQUIRED" and "SHALL"). Then: "A document that follows all MUST-, REQUIRED- and SHALL-level of criteria in this specification that apply to document authors." So is the document really putting requirements on the *authors*? Shouldn't it define requirements on the documents? 1.2.1 Dependencies "Implementations MUST support the http scheme defined in HTTP. Other requirements regarding HTTP are made throughout the specification [RFC2616]." s/scheme/protocol/? 2.1. Members of the XMLHttpRequest Object "If the method argument doesn't match the method production defined in section 5.1.1 of RFC 2616 a SYNTAX_ERR MUST be raised by the user agent. If the user agent doesn't support the given method for security reasons a SECURITY_ERR SHOULD be raised. [RFC2616]" s/method production/"Method" production/ "User agents MUST at least support the following list of methods (see [RFC2616]): * GET * POST * HEAD * PUT * DELETE " Why is OPTIONS missing from this list? "Otherwise, if the nominated request header field already has a value, the new value MUST be combined with the existing value (section 4.2, [RFC2616])." That's a bit misleading. What does "combine" mean precisely? Is the intent to require implementations to assume that the header format is a comma-separated list? In that case, why doesn't the preceding list contain other headers known not to have that format? (c-ext, ext (RFC2774), cookie, cookie2 (RFC2965), if, lock-token, status-uri (RFC2518), label (RFC3253), apply-to-redirect-ref, redirect-ref (RFC4437), ordering-type (RFC3648)). It seems to me that it would be wise for the specification to specify a way to remove a header, so that list-typed headers can be set to a known value reliably. "If data is passed to the send() method it must be MUST for the entity body as defined by section 7.2.1 of [RFC2616])." s/7.2.1/7.2/ "Authors SHOULD specify the Content-Type header..." I think we should add requirements on the client of the API (the script/program), not the author. "If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it MUST be transparently followed (unless it violates security, infinite loop precautions or the scheme isn't supported). Note that HTTP ([RFC2616]) places requirements on user agents regarding the preservation of the request method during redirects, and also requires users to be notified of certain kinds of automatic redirections." 1. Add note: following a redirect requires re-sending the request body, when present. 2. To follow a redirect on a non-safe method without the user's consent is forbidden in HTTP (see RFC2616, 10.2). No, notification is not sufficient. And yes, this also applies to POST. "If the user agent implements server-driven content-negotiation ([RFC2616]) it SHOULD set Accept-Language, Accept-Encoding and Accept-Charset headers as appropriate; it MUST NOT automatically set the Accept header. Responses to such requests MUST have content-codings automatically removed." What does "removed" mean here? If we want to require the implementation to undo the transformation, let's be specific about that. "If the user agent supports Expect/Continue for request bodies ([RFC2616]) it SHOULD insert Expect headers and handle 100 Continue responses appropriately." Are we talking about "Expect: 100-continue"? Then let's be specific about that (there can be other values for "Expect"). Furthermode, RFC2616 requires support for 100-continue anyway (it's not optional), and is also more precise on the requirements (see for instance RFC2616, 8.2.3). In particular: --> "A client MUST NOT send an Expect request-header field (Section 14.20) with the "100-continue" expectation if it does not intend to send a request body." (RFC2616, 8.2.3) "If the user agent can't derive a character stream in accord with the media type specification, reponseText MUST be null." s/reponseText/responseText/ "Note: For HEAD requests this attribute will always be null (it remains unchanged). Similar to the responseXML attribute." I don't like special cases. So will it be null for any response without entity body, or just for HEAD? "...(typically 200 for a successful connection)." s/connection/request/ That being said, it's dangerous to be specific here. In general, all 2xx series codes signal some kind of success. "HTTP requests sent from multiple different XMLHttpRequest objects in succession should be pipelined into shared HTTP connections." That's misleading; HTTP pipelining is something very specific beyond re-using a connection (see <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.8.1.2.2>).
Received on Saturday, 17 February 2007 17:01:03 UTC