Re: Socket APIs and the W3C

On 2006/09/04, at 5:09 PM, Chris Lilley wrote:

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

That presupposes that writing APIs to non-application protocols is  
appropriate for the Web.

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

Those are application protocols, not transport protocols.

>> * 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."),
>
> 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".

[ lots about multiple security models elided ]

Quoting <http://www.w3.org/TR/2004/WD-SVG12-20040510/>:

> The next draft of SVG 1.2 will clearly list the minimum set of  
> security features that an SVG user agent should put in place for  
> these interfaces.
Chris, I didn't say that there should only be a single security model  
-- *one* well-defined security model would do.


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

Received on Tuesday, 5 September 2006 17:15:35 UTC