Re: Socket APIs and the W3C

Hello www-tag,

Mark Nottingham <> wrote:

> By all appearances, the W3C has become a hotbed of socket API
> development.
> A colleague recently pointed out that the SVG 1.2 WD contains a "Raw  
> Sockets" DOM interface;

Which was, at the time, misnamed. Its not raw sockets, just sockets.

>  <>.

An up to date reference would be

>  AFAICT, this is neither covered by its charter
> <>

Update over a network is *specifically* covered by the charter, in the
section 'mission and scope':

  utility DOM interfaces to allow SVG integration with XForms and Web
  Services, for example dynamic update of graphical presentation in
  reponse to information delivered over a network, or submission of
  XForm results over a network.

> Doing so isn't necessarily a bad thing -- after all, the Web is  
> explicitly more than just HTTP

Good point. An earlier draft of the SVG specification attempted to
provide a general interface which was (rightly) criticized for actually
being a glorified HTTP interface

and not really being suitable for protocols that differed from HTTP in
their general model.

In response to these comments, the legacy GetURL and postURL methods
were standardized, primarily for HTTP and similar protocols; and in
response to calls to "give us sockets and we can build the rest" that is
in fact what we did.

This was implemented in, for example, Batik; there is a demonstration
IRC client in SVG, built on top of that. More typical uses are for
dynamic level-of-detail control, or for information visualization fro a
constant stream of data, often delivered in XML.

> -- but it does raise a few questions;
> * How do raw TCP interfaces relate to the Web architecture?

The Web is the universe of network accessible information. Although
occasional attempts are made to make Web==HTTP, this is not and never
has been true.

>  Last time  
> I checked, there was no "tcp" URI scheme. Should a protocol have a  
> well-defined URI scheme before W3C WGs attempt to integrate it?

Thats an interesting point, and certainly for declarative markup its a
reasonable suggestion. For an API its less clear; a URI cannot indicate
all aspects of a connection. The method (for protocols that have
methods) is not indicated, for example nor is it clear how to disconnect
or time out, just from a URI.

> * More generally, what kinds of protocols are appropriate? E.g., why  
> stop at TCP? Why not UDP?

The Web already includes UDP, and its widely used for streaming media
such as audio and video. There are already UDP-based URI schemes too.

> * What, at a minimum, should such API specs include? The SVG draft  
> specified a raw socket API

(sockets, not raw sockets. They have different technical meanings, Its
unfortunate that the SVG spec early on called them 'raw' sockets, in a
colloquial rather than technical sense.)

>  without including a security model (only  
> hand-waving along the lines of "you know what to do; we'll get to  
> it."),

Actually, no, it doesn't say "we'll get to it" at all. The lack of a
single mandated security model is a feature, not a bug and not something
we "didn't get around to".

It also says, as an API specification should, what exception is raised
when the requested connection has been denied by some security policy;
and, as is good practice, that exception merely says that security has
stopped you, without giving further details:

  For security reasons, user-agents are strongly encouraged to restrict
  the ways in which a connection can be established both for both host
  and ports. If the user-agent elects to deny the connection based on
  these restrictions, a GlobalException of type DENIED_ERR must be

In other words, the point is that different security models are
appropriate in different situations.


a) a military system using SVG
b) a web browser using SVG
c) a device UI using SVG, where the content is provided by the system,
   not by the public.

The security requirements are very, very different here. I recall
talking to an AC Representative (active in the general defence sector)
who cautioned strongly against assuming that a security model appropriate
for HTML browsers was suitable also for defence or industrial use.

Similarly some system integrators active in the mobile and embedded
space - who create user interfaces in SVG for assorted devices - were
adamant that SVG should not impose a single security model which would
be inappropriate for many of their uses - as they control exactly the
content that is used, the user cannot add to it or change it. So the
installed content can be trusted.

Thus, SVG applies the principle of orthogonal specifications - security
restrictions are a separate layer, by design, and should remain so.

I note in passing that misguided application of HTML browser security
models also affects the Semantic Web. "You can't link to that, its on a
different server" does not work well with a global network effect; and
proxying to get around security restrictions (the usual method of
defeating HTML browser security restrictions) breaks SemWeb by requiring
different, duplicate URIs to be used rather than the correct ones
(again, contrary to Web Architecture).

"Oh and you have to set security to off" is fine for a browser-based
SemWeb demo, but not something that can be expected for a deployed,
real-world SemWeb system. A range of security models is needed, as

 Chris Lilley          
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 5 September 2006 00:10:11 UTC