- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 17 Nov 2003 08:20:02 +0900
- To: www-tag@w3.org
Nov 15 10:05:04 <Ian> Action DC: Provide text for 1.2.1 of where this wasn't done and resulting pain. Brought to you by 4am jet-lag... Probably needs work... --- The core of the HTTP, HTML, and URI specifications are orthogonal, but * The forms section of the HTML specification includes a protocol extension of sorts that specifies an encoding of form data sets as URI query strings. The design works reasonably well (except for some I18N bugs; see the get7 finding), but it might be easier for developers of, for example, CGI[cite] applications to find if it were specified separately and cited informatively from the HTTP and URI specifications, as well as normatively from HTML. * There are some HTTP header fields specified in HTML (refresh@@?). This is a clear abstraction violation; the developer community deserves to be able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). * There is an idiom for declaring the character encoding scheme of an HTML document using http-equiv. By design, this is a hint that servers should emit a corresponding Content-Type header field, but the user of the hint in servers is not widely deployed and in practice many user agents peek inside the HTML document in preference to the Content-Type header field; this works against the principle of authoritative representation metadata as discussed in section 3.4; the the TAG finding "Client handling of MIME headers" elaborates on the resulting security issues etc. --- -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Sunday, 16 November 2003 18:20:06 UTC