Re: Socket APIs and the W3C

* Mark Nottingham wrote:
>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/>.

You are looking at rather outdated documents, the socket interface is
part of the recently published Candidate Recommendation for SVG Tiny
1.2, see <http://www.w3.org/TR/SVGMobile12/svgudom.html>, and the re-
quirements are at http://www.w3.org/TR/2006/WD-SVGTiny12Reqs-20060810
The requirement addressed here is "SVGT 1.2 should support rendering
level of detail".

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

Yes, several people in fact disagreed with the SVG Working Group that
SVG Tiny 1.2 should include this feature due to overlap with the Web
API Working Group and serious security problems. The Director did not
agree with this "minority" view, however.

>* 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?

Your last question is a process question and therfore out of scope of
this list. As for the first question, I don't see which architecture
principles need to be clarified in the context of socket APIs.

>* 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?

This is again a process question.

>* 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.

Again, I don't think there are architectural principles that need to
be clarified here. As far as security is concerned, the SVG Working
Group rejected security concerns raised during the four last call
reviews of the feature. While several reviewers were not satisfied
with how the Working Group handled this issue, they did not register
a formal objection, in the opinion of the SVG Working Group, however.

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

Just look at <http://www.w3.org/TR/2004/WD-SVG12-20041027/>:

  The Connection interface provides an API for socket-level communication. 
  
  interface ConnectionEvent : events::Event { // "ConnectionData" event
     readonly attribute DOMString data;
  };
  
  interface Connection : events::EventTarget {
     readonly attribute boolean connected;
     void setEncoding( DOMString value ); // might be called before connect
     void connect( in DOMString url ) raises(DOMException)
     void send( in DOMString data );
     void close();
  };
  
  A Connection object is created using the SVGGlobal interface. 

This is the whole Last Call specification text, edited by W3C's
Rich Web Clients Activity Lead, published by a group chaired by
W3C's Interaction Domain Lead. No prose, no examples, no error
handling, this is all there was. Now, of course people outside
the Working Group reviewed this and complained,

  http://lists.w3.org/Archives/Public/www-svg/2004Sep/0094.html
  http://lists.w3.org/Archives/Public/www-svg/2004Oct/0144.html
  http://lists.w3.org/Archives/Public/www-svg/2004Nov/0065.html
  http://lists.w3.org/Archives/Public/www-svg/2005Jan/0004.html
  http://lists.w3.org/Archives/Public/www-svg/2005Feb/0090.html
  http://lists.w3.org/Archives/Public/www-svg/2004Nov/thread.html#17
  http://lists.w3.org/Archives/Public/www-svg/2004Nov/0430.html
  http://lists.w3.org/Archives/Public/www-svg/2004Nov/0481.html

but the SVG Working Group did not bother to formally address any
of the comments, or at least to make any subtantial improvements to
the specification as you can see in the next Last Call Working Draft

  http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/svgudom.html

So, to answer you question, such APIs won't be reviewed at all.
While you might be concerned about this process-wise, as you can
read in http://lists.w3.org/Archives/Public/www-svg/2006Aug/0036
The Director did not agree that there might be a process problem
anywhere in the development of the SVG 1.2 specifications.
-- 
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, 3 September 2006 16:05:50 UTC