Socket APIs and the W3C

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; <http://www.w3.org/TR/2004/WD-SVG12-20040510/ 
#rawsocket>. AFAICT, this is neither covered by its charter <http:// 
www.w3.org/2004/10/svg-charter.html> or in the referenced  
requirements document <http://www.w3.org/TR/SVG2Reqs/>.

Additionally, the Web APIs WG is chartered <http://www.w3.org/2006/ 
webapi/admin/charter> to produce:

> API specifications for other network communication methods.
> Network communication methods covered by this deliverable are  
> network sockets and possibly protocols other than HTTP. This allows  
> a Web application to perform more networking operations (eg. IRC,  
> other instant messaging protocols, Java Message Service and Session  
> Initiation Protocol). Also, it may be necessary to produce  
> documentation for, or a specification of, connection policy and  
> security.
> Tentative milestones: First draft of specification during December.  
> Candidate Recommendation 4th quarter of 2006.
IIRC people there have mused about including a raw TCP interface, to  
permit the most general use.

Doing so isn't necessarily a bad thing -- after all, the Web is  
explicitly more than just HTTP -- but it does raise a few questions;

* How do raw TCP interfaces relate to the Web architecture? 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?

* More generally, what kinds of protocols are appropriate? E.g., why  
stop at TCP? Why not UDP? Or raw Ethernet frames? JMS is mentioned,  
even though it's not a wire protocol -- it's an API specification  
that is implemented by many proprietary protocols. Is that something  
the W3C should be encouraging?

* What, at a minimum, should such API specs include? The SVG draft  
specified a raw socket API without including a security model (only  
hand-waving along the lines of "you know what to do; we'll get to  
it."), and it still stands that way two years later.

* How will such APIs be reviewed to assure security and protocol  
alignment?

Any guidance the TAG could give would be helpful, I'm sure.

Thanks,

--
Mark Nottingham     http://www.mnot.net/

Received on Sunday, 3 September 2006 14:16:28 UTC