SVG12: Network Interfaces

Dear Scalable Vector Graphics Working Group,

  In http://www.w3.org/TR/2004/WD-SVG12-20041027/api.html the Network
Interfaces are about as underdefined as possible as several reviewers
have pointed out. Please change these such that the following is well-
defined and the following functionality is guranteed.

  * Which schemes (http, https, data, ftp, ...) must be supported?
  * Which protocols (HTTP/1.0, HTTP/1.1, ...) must be supported?
  * Which character encodings must be supported?
  * Which Transfer- and Content- encodings must be supported?
  * Which media types must be supported?
  * What is the integer constant for `ABORTED`?
  * What is a `URLResponse` event, how is it defined?
  * What is a NameValuePair, how is it defined?
  * What happens if a request is made for an unsupported scheme?
  * What happens if a request is made but the implementation does
    not allow such a request?
  * How are requests to be constructed, e.g., is it acceptable
    for implementations to apply Transfer- and/or Content-Encodings?
  * What happens if a HTTP delivered gzip-compressed image/svg+xml
    resource is requested which does not indicate the compression
    in the header? Would responseText throw an exception or are
    implementations required to sniff for the compression and un-
    compress the resource accordingly? (This depends of course on
    the response to other comments.) What if the type is application/
    xml, are such resources sniffed for XML aswell?

  // how are the request URI characters converted to octets
  URLRequest.init("http://www.example.org/björn", "GET");

  // is NFC normalization for the request URI performed
  URLRequest.init("http://www.example.org/bjo\u0308rn", "GET");

  // can other HTTP methods be used, what happens if not
  URLRequest.init("http://www.example.org/example", "DELETE");

  // what happens for illegal request URIs
  URLRequest.init("http://example.org/%u00F6", "GET");
  URLRequest.init("http://user:pass@example.org/", "GET");

  // is support for the data: scheme required for URLRequest and
  // if, how can the data be retrieved, e.g., would this work:
  URLRequest.init("data:image/svg+xml...", "GET");

  // what happens if the "same" header is specified multiple
  // times, e.g., would the following yield in "X: y\nX: z"
  // or "X: z" or "X: y" or "X: y,z"
  ...init("http://example.org", "GET");
  ...addRequestHeader("X", "y");
  ...addRequestHeader("X", "z");

  // what happens if non-ASCII characters are used as values
  // for specific headers, are these encoded as defined in
  // RFC 2616 for HTTP requests or are these UTF-8 encoded
  // and passed literally, or are they ignored, or does this
  // trigger an exception, etc.
  ...init("http://example.org", "GET");
  ...addRequestHeader("X", "\u20AC");

  // How are response headers decoded to DOMString, for example,
  // the response to a HTTP request might have
  //
  //   X: =?utf-8?q?Bj=C3=B6rn?=
  //
  // Is it for implementations of HTTP guranteed that this will
  // result in a value of "Björn" as defined in RFC 2616? What if
  // there are encoding errors?
  (...getResponseHeader(x).??? == "Björn") == true

  // what happens if an illegal request is constructed, e.g., if
  // an empty value is specified for a header that requires a
  // value, are implementations required to perform the request
  // anyway, or may they throw an exception or attempt to correct
  // the error?
  ...init("http://example.org", "GET");
  ...addRequestHeader("Accept-Charset", "");

  // what happens if a HTTP request is constructed that does not
  // include a Host: header? Would implementations add this header
  // automatically? What happens if implementations are required
  // to add such headers and conflicting headers are specified?
  ...init("http://example.org", "GET");
  ...addRequestHeader("Host", "example.com");

Please change the names of the responseText and requestText attributes,
these names are misleading as they do not return textual representations
of the request/response but rather a textual representation of the
content.

Please change the statusText property such that implementations can
provide meaningful text in case of errors to allow developers to provide
more meaningful hints to users on why a request failed.

Please change the init method to allow all HTTP methods.

Please change the draft such that it is clear for all conditions that
raise a DOMException what type of DOMException is raised.

Please change the examples in this section to use addEventListenerNS
rather than addEventListener.

Please change the URLRequest interface such that response headers can be
accessed by name rather than by iterating over the list of headers.

It is not clear why the File interface has methods to retrieve represen-
tations of the data in Base64 and HeyBinary but URLRequest does not;
please either add corresponding facilities to URLRequest or remove these
from the File interface or state clearly why these are inconsistent.

It is not clear at all how URLRequest can be used to transfer XML and
in particular XML as generated by printNode(). How the requestText DOM-
String is converted to octets is not clear at all. Clearly, the request
must be constructed such that it corresponds to the encoding declaration
in the XML document, but that does not seem possible. For example, if
printNode() returns (without a BOM, printNode must not add it as that
would likely cause parseXML to be unable to parse the string)

  <?xml version="1.0" encoding="UTF-16"><x/>

the requestText would need to start with a byte order mark and UTF-16
encoded, but how is URLRequest supposed to know? It cannot parse the
beginning of the document as it does not know whether this is an XML
document or some other text that happens to look similar. Please rework
this interface to gurantee simple, efficient and interoperable XML/HTTP
transmission.

Please add an example that demonstrates proper use of the reworked
interface to POST printNode generated XML via HTTP.

It is not clear at all how implementations are required to determine the
character encoding of the requested resource in order to provide strings
ala responseText, please change the draft such that deterministic
results are guranteed.

The same applies to the Connection interface, it is not clear how data
is converted into octets and incoming octets into bytes. What is the
default encoding if setEncoding() is not used, does setEncoding() apply
to both incoming and outgoing data, what happens if there are encoding
errors, what character encodings must be supported, is incoming data
normalized in NFC, ... Please change the draft to define all these
things.

Please change the Connection.send method such that it throws exceptions
if data contains characters that cannot be encoded in the encoding that
is specified via setEncoding (assuming it applies to outgoing data).

Please change setEncoding() such that it throws an exception of the
specified character encoding is unsupported.

Please change the connect method to take two parameters host and port
(and maybe proto to define whether TCP or UDP should be used) to specify
destination. It makes no sense to connect to a "url" and it would only
cause implementers and developers to agree on unregistered schemes
such as "tcp://..." or weird use of e.g. "http://example.org:6667" to
connect to an IRC server.

Please change the draft such that it is clear what happens if close()
is called for connection that is not yet open or already closed.

Please change the draft such that it is clear what happens if connect is
called for a connection that is already open.

Please change the draft such that it is clear what happens if send() is
called for a connection that is not open.

Please add an example that demonstrates proper use of the Connection
interface to send printNode generated XML somewhere.

regards.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 20 February 2005 08:26:26 UTC