Re: [whatwg] Problem with keygen in html 5
On Wed, 8 Apr 2009, Stefan Santesson wrote: The PKIX work group is responsible for the PKI related standards produced in the IETF, among those the very first certificate standard RFC 2459. RFC 2459 is referenced through out section 4.10.11. The keygen element. The problem is that RFC 2459 was obsoleted years ago by RFC 3279 and RFC 3280 back in 2002. RFC 3280 was further Obsoleted by RFC 5280 in 2008 while RFC 3279 has been updated by the RFCs 4055, 4491 and 5480. I really don't understand any of the crypto stuff, but I've tried to update the references to point to the current RFCs. Let me know if I got anything wrong. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Parsing RFC3339 constructs
On Tue, 11 Aug 2009, Julian Reschke wrote: Ian Hickson wrote: On Mon, 27 Apr 2009, Asbjørn Ulsberg wrote: On Mon, 27 Apr 2009 12:59:11 +0200, Julian Reschke julian.resc...@gmx.de wrote: - the literal letters T and Z must be uppercase Any technical reason why they have to? Any reason why they don't? It simplifies processing a tiny amount. So for a tiny win, you change the format? By a tiny amount, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Parsing RFC3339 constructs
Am Dienstag, den 11.08.2009, 07:27 + schrieb Ian Hickson: On Tue, 11 Aug 2009, Julian Reschke wrote: Ian Hickson wrote: On Mon, 27 Apr 2009, Asbjørn Ulsberg wrote: On Mon, 27 Apr 2009 12:59:11 +0200, Julian Reschke julian.resc...@gmx.de wrote: - the literal letters T and Z must be uppercase Any technical reason why they have to? Any reason why they don't? It simplifies processing a tiny amount. So for a tiny win, you change the format? By a tiny amount, yes. It will be interesting to see if parsers choose to also get lowercase letters. I'd half-expect that to work, not at least because there may already be RFC-compliant libraries in the wild. So if they do by the time HTML n is the standard, will the uppercase restriction be removed in HTML n+1 ? Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] A tag for measurements / quantity?
On Tue, Aug 11, 2009 at 12:58 AM, Max Romantschukm...@romantschuk.fi wrote: Hi Everyone, I've been off the list for quite some time, so bear with me if I missed something searching the archives. I've been looking at the meter element, which specifically states that There is no explicit way to specify units in the meter element, but the units may be specified in the title attribute in free-form text. Having used the web for the past 15 years I've always felt that it's a shame when you run into a page with a set of measurements and those can't be interpreted automatically in a sensible fashion. Especially with the fact that there are both imperial and metric units still around in this day and age. An backwards compatible inline element to specify a quantity would be rather trivial: quantity unit=cm12 cm/quantity quantity unit=kg2 kg/quantity With this implementation a number inside the quantity element would be interpreted as the numerical value of the unit. Other characters would be ignored. That way old browsers would simply ignore the unknown tag, whereas a browser aware of this tag could provide DOM hooks for things like implementing a browser extension to convert between metric and imperial units. Food for thought. Opinions, anyone? It would be good if @unit could be omitted and parsed from the content as well in simple cases. In both of the examples you provide, it would be trivial. /(\d+)\s*([a-zA-Z]*)/ would capture the quantity and the unit in most cases. I think a stronger case would be to provide automatic conversions to one's preferred quantitative units, as has been discussed as a possible use for time. Are there stronger use-cases for this than just auto-conversion, though? time, frex, allows for easy machine-scraping of time/date data for adding things to calenders. ~TJ
Re: [whatwg] Test results for xmlns:foo attribute preservation across all browsers
On Mon, 10 Aug 2009 11:37:15 -0400, Bil Corry b...@corry.biz wrote: Charles McCathieNevile wrote on 8/6/2009 2:24 PM: On Thu, 06 Aug 2009 15:12:07 -0400, Manu Sporny mspo...@digitalbazaar.com wrote: The test ensures that attributes originating in the markup of an HTML4 document are preserved by the HTML parser and are preserved in the DOM. [...] http://html5.digitalbazaar.com/tests/xmlns-attribute-test.html We have verified that xmlns:-style attributes are preserved in the following browsers: Also works in the latest Opera 10 Beta 2 plus Unite snapshot. Opera 10 - Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00 (yeah, the UA string is like that because important websites with browser sniffing check version numbers, but only the first digit. I.e. they can't count to ten yet). The issue now is that websites that can't count to ten will not realize it because their site continues to function properly. Well, they won't realise it through seeing their site break in Opera. And for sites that can count to ten, well, you've broken them too. My own sniffer reports version 9.80 for the above UA string whereas if it was still in the normal Opera format, it would correctly report version 10.00. I'm glad you are smarter than the average bear, and I am sorry that we don't have a reward for that. But in practice, we are forced to decide whether it is better to catch the attention of web designers by making their site not work (with the incidental cost of catching the attention of users who discover that the site doesn't work), or by some other means. Our experience suggests that the former is simply not effective - and this is one of the reasons WHAT-WG began - to deal with the Web in practice, and look for ways to improve HTML that didn't require browsers to suddenly stop working for reasons that, *to the user* are mystifying and cause them to blame the browser. So yeah, this is clearly a sub-optimal situation and we want to change it. That alone won't make the change - which is why Opera pays people specifically to go around fixing web sites, code libraries, etc. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Alt attribute for video and audio
On Mon, 10 Aug 2009 10:42:36 -0400, Remco remc...@gmail.com wrote: On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. Must at least means that if you can't do it right, here is how to get it only half-wrong (i.e. not good practice, but enough to be useful anyway) title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you ant to provide an alternative, then I suggest that is not a good one. It is a description of the video, rather than a replacement. An alternative is something more like As a ball falls, every second it goes 9.8m/s faster than it was going a second before, because gravity makes it accelerate. In practice, effects such as drag (wind resistance) will affect the actual speed - and the value of 9.8 is specific to the average sea-level of earth - it depends on the mass of the earth and the ball. If you already have this in the preceeding or following text, something like Benjamin's examples, then the job is done and repeating it in alt is redundant and bad practice. To be clear, your example text is better than nothing - and in accesibility that is often as good as it gets :( But there's value to explaining how to do things better - and this particular issue is something that has gathered a *huge* amount of discussion and explanation over the last decade and a half. [snip] To be clear, I think that the existing options for video in HTML5 are better than anything we would gain by adding an alt attribute. The only value I can see in adding one is that some people who are careful enough to use it with images will also use it effectively even if they will do nothing better - but this would require careful large-scale study of authors *as they work* to verify, and I doubt that is going to be done. -- Benjamin Hawkes-Lewis One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. The question now is: why would we need both figure and aria-describedby? Because many designers will not put sufficiently complete text explanations of everything in the ordinary flow of a document. This is actually a valuable accessibility practice - the large number of people who have difficulty reading can often find that their ability to use content is significantly reduced by the presence of large blocks of text. This is something that most usability engineers and communication experts understand instinctively, actually. So we need some way that allows for more than one presentation scenario. Either we ask people to make multiple pages (something that is well-known to suffer from the out of sight out of mind problem, or we provide ways to manage more information in a single page (which also suffers from the problem, but it is believed less so. I don't know how many careful studies have been done of this, if any). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Codecs for audio and video
2009/8/11 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net: Am Dienstag, den 11.08.2009, 00:44 +0100 schrieb Sam Kuper: In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/ At this point, this seems to be pure speculation. Maybe Google representatives can chime in on this issue ? I think it would be entirely reasonable to let Google get on with what they're doing on their schedule and count our chickens precisely when they hatch ;-) But with the results the Xiph/Mozilla/Wikimedia team have managed to get with the Thusnelda encoder for Theora - comparable results to H.264 - a released open unencumbered codec with a big company defending its freedom could get very good indeed in reasonable order. - d.
Re: [whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
On Wed, 22 Jul 2009, Sebastian Markb�ge wrote: The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. The spec requires them to all be set on all drag events, currently. This issue is related to whether or not a DragEvent is infact a MouseEvent. It is. The current drag specifies that User agents must, every 350ms (�200ms), perform the following steps in sequence.. It doesn't make sense to trigger this event if nothing has changed based on time alone. There's a lot about this model that doesn't make much sense. I think we're long past that point. :-) All current implementations trigger this sequence faster if the mouse is moving. Effectively treating mouse movements as new drag events. Just like mousemove. IMO, it should be specified that mouse movements triggers a new iteration of this sequence, and that current mouse position should be a part of the event. Until we have a user interaction events specification that says what a mouse movement really is, I don't want to specify anything here that would be detailed in that way. The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. I've added more text to clarify what it means in the case of the mouse not being used. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] syncing attachments to an offline-capable client?
On Wed, 22 Jul 2009, Aaron Whyte wrote: It'd be a lot better to have a JS API to capture new URLs. We actually had this in an earlier version, but we removed it based on feedback from browser vendors that it was too much at once. I expect we'll readd this feature in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] File API features in HTML5
On Thu, 6 Aug 2009, Jonas Sicking wrote: I'm not sure how to expose the presence of data during the drag, though. I think we currently list application/x-moz-file in the .types property. Obviously we'd like to use a better type than that. Could we simply use application/file? Do we need to register the type with IANA? I expect yes. I ended up just using Files as the magic string. ...and I got around to specifying that .types is accessible even during the events where the DataTransfer is empty. (I really should just rewrite how the model is described, but oh well.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alt attribute for video and audio
On Tue, Aug 11, 2009 at 8:20 PM, Charles McCathieNevilecha...@opera.com wrote: On 10/08/2009 04:05, Remco wrote: But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you ant to provide an alternative, then I suggest that is not a good one. It is a description of the video, rather than a replacement. An alternative is something more like As a ball falls, every second it goes 9.8m/s faster than it was going a second before, because gravity makes it accelerate. In practice, effects such as drag (wind resistance) will affect the actual speed - and the value of 9.8 is specific to the average sea-level of earth - it depends on the mass of the earth and the ball. Actually, you have provided here not only a description of the video, but also an explanation of why things happen. The video shows a ball falling down and a speedometer increasing with 9.8 m/s per second. Nothing more. My text is simply a replacement for the video. It tells precisely what happens, and nothing more. Of course, you need to see the video (or the replacement text) in context of the Wikipedia article. Without context, neither alternatives make sense. One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. The question now is: why would we need both figure and aria-describedby? Because many designers will not put sufficiently complete text explanations of everything in the ordinary flow of a document. This is actually a valuable accessibility practice - the large number of people who have difficulty reading can often find that their ability to use content is significantly reduced by the presence of large blocks of text. This is something that most usability engineers and communication experts understand instinctively, actually. Ah yes, you're right. So we need some way that allows for more than one presentation scenario. Either we ask people to make multiple pages (something that is well-known to suffer from the out of sight out of mind problem, or we provide ways to manage more information in a single page (which also suffers from the problem, but it is believed less so. I don't know how many careful studies have been done of this, if any). In general I think ARIA needs to be better integrated with HTML. Right now it's just a bunch of additional attributes that don't have a functional purpose for Normal People (TM). It's strictly a foreign extension to HTML that is only really useful for people that care about accessibility (say, 1% of the web author population). Most attributes even have the 'aria' prefix, which tells you that you need to learn some standard for disabled people before you can use this. It would be nice if all ARIA roles could be made into first-class HTML elements. That way, I only have to build my constructs once, and it's accessible implicitly. At the moment, some roles have native HTML counterparts, while others do not. The above has been discussed before, so I'll just add my voice to the choir: the ideas of ARIA desperately need to be integrated into HTML, because as it stands, it will *not* be used. As a small part of integrating the ideas of ARIA into existing HTML 5, I just got an idea for a better solution for replacement content for video and audio: source. The source element is used to provide media elements with multiple sources. What if one of those sources could be an element on the page itself? The text is just another source which could link off-page, or on-page. video source type=video/theora src=primary-content.ogg source type=text/html src=#alternate-content source type=text/html src=alternate-content.html /video Alternative content in source which comes from an element on the same page is an extension to what you already know, and it doesn't require you to know about a special accessibility part of HTML. In addition: currently, source is only used for audio and video, but why not extend it to any external element? iframe src=primary-content.html!-- legacy -- source type=text/html src=primary-content.html source type=text/html src=#alternate-content source type=text/html src=alternate-content.html /iframe objectsource ... source ... /object embedsource ... source ... /embed imgsource ... source ... /img That last one may be problematic,
Re: [whatwg] BWTP for WebSocket transfer protocol
Wellington Fernando de Macedo wrote: message segmentation (...) aren't much important in bidirectional-communication. No. I'm wrong. Because of virtual connections message segmentation is necessary. I think WS could support these features (like they are specified in the BTWP proposal) through its websocket-protocol header. In such a way the WS could work with both protocols. Wellington, I too agree that the ws protocol as proposed could be improved to support some of the key features that are being discussed here. I actually started this by proposing some such extensions to the ws protocol. However, I have reservations about creating an entire protocol that will effect servers, proxies gateways and browsers on the basis of a single JavaScript API. I think the protocol for bidirectional communication over the internet should be considered and designed with uses other than just the js API.There are many other uses for bidirectional communication over the web that will bypass firewalls. The authors of the websocket protocol are looking for the simplest protocol that will support their current API. Thus the suggestions to include virtual channels, extensible mime-types and segmentation were deemed too complex. Thus I think it is the IETF that really needs to come to the party with a multi-purpose protocol proposal that will satisfy all bidirectional web use-cases, not just the js API. Thus the hybi effort at IETF is looking at bidirection web, rather than just websocket. cheers
Re: [whatwg] autobuffer on new Audio objects
On Fri, 31 Jul 2009, Nils Dagsson Moskopp wrote:
Am Freitag, den 31.07.2009, 00:26 + schrieb Ian Hickson:
On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote:
I second that motion, not only as owner of a smartphone, but also as
someone with webspace that has a volume cap. Automagic audio element
buffering could deter web authors from dynamically putting more than
one element on a page, thus reserving javascript playlist widgets to
those who can afford more bandwith on an order of magnitude (!).
This doesn't apply to elements on the page, only to script-created
elements.
I was referring to exactly that. Creating an audio element for every
audible file in a directory isn't something one would necessarily do on
the server side.
But as long as there is a possibility to not trigger buffering when
creating media objects, all may be well.
The idea of the attribute is to ensure the UA has the final say on this
stuff, rather than having scripts that force buffering by seeking to a
bunch of places in the file or something equally asinine.
On Fri, 31 Jul 2009, David Wilson wrote:
I still don't understand the 'why' of this, whereas the 'why not' seems
clear. It might be useful (in a saving an extra line of code kind of
way), but the fact it implicitly causes potentially high bandwidth IO
seems more wasteful than convenient.
The benefit is that most authors won't notice if they forget to include
the attribute, and this would lead to stuttering on slow connections.
What about adding an autobuffer parameter to the constructor which
defaults to false?
I think this would have the same effect as not including the argument at
all, since most authors wouldn't think about it.
I don't think the intent of creating Audio instances clearly always
means playback will happen.
What other use cases do you have in mind?
The playlist example given doesn't seem that unreasonable, it's
something an unsuspecting developer might do in a hurry.
It's a good idea to make types as general as possible, particularly for
browsers where libraries like jQuery make it convenient to treat DOM
nodes as data structures. Forcing a user to type extra
(document.createElement('audio')) in order to avoid surprising
functionality doesn't seem right.
I think there is some merit to this line of argumentation, yes. I don't
think it outweighs the concern over sound effects stuttering, though,
especially since the only disadvantage in the playlist case will be that
the audio is prebuffered, leading to a better experience in that case too.
It's easy to see how some naively implemented JS audio widget could
fetch 200mb over an expensive 3G connection, simply by navigating to
some site in a background tab (say, by creating an array of elements
to represent their playlist - something I'd have thought was
perfectly valid behaviour).
A mobile phone would not autobuffer in a background tab
3G doesn't mean mobile phone. I barely use my phone's browser, but use
net via Bluetooth all the time, various Dell laptops come with 3G
available as an option built in, for many in Africa its the only
available network, etc.
Indeed, systems should detect these situations and not autobuffer when
they apply.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
Am Mittwoch, den 12.08.2009, 00:05 + schrieb Ian Hickson: On Fri, 31 Jul 2009, Nils Dagsson Moskopp wrote: Am Freitag, den 31.07.2009, 00:26 + schrieb Ian Hickson: On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote: I second that motion, not only as owner of a smartphone, but also as someone with webspace that has a volume cap. Automagic audio element buffering could deter web authors from dynamically putting more than one element on a page, thus reserving javascript playlist widgets to those who can afford more bandwith on an order of magnitude (!). This doesn't apply to elements on the page, only to script-created elements. I was referring to exactly that. Creating an audio element for every audible file in a directory isn't something one would necessarily do on the server side. But as long as there is a possibility to not trigger buffering when creating media objects, all may be well. The idea of the attribute is to ensure the UA has the final say on this stuff, rather than having scripts that force buffering by seeking to a bunch of places in the file or something equally asinine. Oh, now I get the similarity to the autoplay attribute. No further questions, your honor and thanks for taking your time to explain this. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Any thought on html5 video tag behind squid proxy !!
On Fri, 31 Jul 2009, narendra sisodiya wrote: most of the traffic of university hostel's and home users goes for streaming media like YouTube. And most of the time we are connected behind proxy for example my institute use squid proxy. But as per my knowledge, squid is not successful to cache the flash based (ex YouTube) video. I do not know the behaviour of html5 video tag but If it is possible to cache such video in proxy then huge bandwidth will be saved!! As designed, there is no reason the HTML5 video element would be incompatible with proxies caching content. If caching does not occur, I would recommend contacting the Web site's developers (they may be disabling caching of video files), the proxy vendor (they may be disabling caching of large files or of file fragments), and the browser vendors (they may also be disabling caching of large files or of file fragments). Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Empty html manifest= attribute handling.
On Fri, 31 Jul 2009, Michael Nordman wrote: How empty html manifest= attribute values are handled in the section 9.2.5.5 may want some massaging. http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#parser-appcache If the Document is being loaded as part of navigation of a browsing context, then: if the newly created element has a manifest attribute, then resolve the value of that attribute to an absolute URL, relative to the newly created element, and if that is successful, run the application cache selection algorithm with the resulting absolute URLwith any fragment component removed; otherwise, if there is no such attribute or resolving it fails, run the application cache selection algorithm with no manifest. The algorithm must be passed the Document object. This ends up passing the value of the document url into the cache selection algorithm as the manifest url, which will initiate an update and all that. Correct. A couple of things that may make sense. 1) equate html manifest= with html treat empty as non-existent. 2) don't resolve the url if the attribute value is empty, pass an empty url to the cache selection algorithm, and have that algorithm flag such resources as foreign if it was loaded from an appcache Both of these prevent the initiation of an update that is doomed to fail. I don't see much point in hardcoding defenses against this case. If it fails it fails. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3515 - [e] (0) Clarify 'font' serialisation.
On Sat, 1 Aug 2009, Simon Pieters wrote: I think CSSOM says font names should be quoted. Oops, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] BWTP for WebSocket transfer protocol
On Tue, Aug 11, 2009 at 2:45 PM, Wellington Fernando de Macedowfernandom2...@gmail.com wrote: Hi, I've looked at the BWTP proposal. My feedback is here :) One thing that I was curious to get your input on is: Does the fact that BWTP syntax looks a lot like HTTP make implementing a BWTP client in gecko any easier? I.e. if we decided to use BWTP rather than WS as protocol, would we benefit from the fact BWTP is HTTP based? / Jonas
Re: [whatwg] BWTP for WebSocket transfer protocol
On Tue, Aug 11, 2009 at 4:50 PM, Greg Wilkinsgr...@mortbay.com wrote: Wellington Fernando de Macedo wrote: message segmentation (...) aren't much important in bidirectional-communication. No. I'm wrong. Because of virtual connections message segmentation is necessary. I think WS could support these features (like they are specified in the BTWP proposal) through its websocket-protocol header. In such a way the WS could work with both protocols. Wellington, I too agree that the ws protocol as proposed could be improved to support some of the key features that are being discussed here. I actually started this by proposing some such extensions to the ws protocol. However, I have reservations about creating an entire protocol that will effect servers, proxies gateways and browsers on the basis of a single JavaScript API. I think the protocol for bidirectional communication over the internet should be considered and designed with uses other than just the js API. There are many other uses for bidirectional communication over the web that will bypass firewalls. Can you suggest changes to the WS protocol that would make it a better general-purpose protocol? You've suggested multiplexing, segmentation, per-frame mime-type and per-frame meta-data so far. Is there anything else that is needed? It would also be good to know what use cases you have in mind for all of these features in order to evaluate them. / Jonas
Re: [whatwg] BWTP for WebSocket transfer protocol
Jonas, Jonas Sicking wrote: Can you suggest changes to the WS protocol that would make it a better general-purpose protocol? There were several threads on the IETF HYBI mailing list with some such proposals: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html An example of such a message is at the bottom of this email. However, the response to such proposals was pretty much that they were too complex and not needed for the ws API. It was the result of those interactions that suggested to me that a bidirectional web protocol would be best developed at arms length to the websocket API, and thus the BWTP effort was born. So far the feedback I have received on BWTP is suggesting that it has perhaps gone a little too far the other way and that there are probably some significant simplifications that can be achieved without greatly restricting the feature set. You've suggested multiplexing, segmentation, per-frame mime-type and per-frame meta-data so far. Is there anything else that is needed? It would also be good to know what use cases you have in mind for all of these features in order to evaluate them. Predicting the future is always hard, but using the present as an indicator is good start. Currently the majority of the web traffic is carried over HTTP which is capable of multiplexing, segmentation, per-frame mime-type and per-frame meta-data. I don't see why adding bidirectional capability should result in any significant reduction in these capabilities of web transports. For example, HTTP can well transport a vast array of content types with meta data support to negotiate accepted languages, types and encodings. The ws API can only handle UTF-8 text datagrams, so as a result the ws protocol has special case handling for UTF-8 text datagrams. So I think that our starting point should be to develop a bidirectional protocol that can well support the current web transport capabilities. I would say that anybody who wishes to advocate a less capable transport should be ask to make the case of why capabilities should be lost with bidirectional protocols. regards Example proposal to improve websocket protocol that was rejected: Greg Wilkins wrote: It would be great if the websocket proposal could include standard definitions for mime encoded datagrams. Current frame types are: 0x00 - sentinel framed UTF-8 message 0x80 - length framed binary data. I'd like to see two additional frame types supported by default: 0x01 - sentinel framed UTF-8 encoded MIME message 0x81 - length framed MIME message. Both these data types would contain a data that commenced with a standard mime header (RFC 2045). The header is optional and terminated by CR LF CR LF. Thus these types have a minimal overhead of 4 bytes. For both these types, any Content-Length header will be ignored and the length indicated by the websocket framing minus the header length will be used. For 0x01 types the content type is assumed to be text/plain; charset=utf-8 If a content type header is specified, it must be text/; charset=utf-8 For 0x81 the content type is assumed to be application/octet-stream unless otherwise indicated. The websocket API would need to be slightly extended to support some common types of message. I would suggest that onmessage always be called for all text mime types, but with some additional parameters: eg. onmessage(text,mimetype,headers) The browser would be responsible for converting the transported charset to the charset of javascript. If the conversion could not be done, then the message would be discarded. Additional events could be supported if you want the browser/server to do the parsing for your. For text/xml text/html: ondocument(dom,headers) and for text/json onobject(object,headers) To send such messages, the API would also need to support void postMessage(data,headers); I think this is a minimal change to websocket and would go a long way to address many of the concerns raised here.With the ability to send standardized meta data, then the job of coming up with standardized multiplexing is much much simpler.
