W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Re: [minutes] F2F meeting Feb 1st

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 10 Feb 2012 15:42:52 -0800
Message-ID: <CABcZeBNXdLXzzb52YWeuj+p=uTgmPWq-F=qtATtm65vEN1L9kQ@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: public-webrtc@w3.org
>  ekr: As a strawman, I believe we don't need capabilities at all.

Trying to avoid sounding stupider than necessary here. I don't think
I claimed that I actually thought this...

I'd suggest that what I was trying to say was more like
"As a strawman, can we get arguments that we need capabilities at


>  fluffy: I believe for some of the applications I want, I want to
>  know if I'm getting video from the front or back video camera.
>  ... Let's just say my application only ran on devices with two
>  cameras, front and back.
>  ... Matthew Kaufman has brought up this example many times: you may
>  very regularly have a workstation in front of you with three
>  monitors with three webcams, and only one of those is the right one.
>  anant: Taking what current web applications do today is probably not
>  the best, but for the second point, what is actually available is
>  very transient.
>  ... So for example, the best model is to try to do what you want,
>  and fail if the resources aren't available.
>  ... For example, Skype will let you try to start a call with no
>  camera, and start a configuration wizard.
>  Ted_Hardie: I totally disagree.
>  ... Presence systems are a great example. Not only do I want to know
>  what I have, I want to know what the other guy has.
>  ... Let's face it, there are applications out there that people do
>  where you might actually select people to talk to based on their
>  current capabilities.
>  ... One of the things that came up was the dating up. I might be
>  more willing to talk to someone on a dating site if I can see they
>  have a video camera and it's not just typing back and forth.
>  ... But I do think that we have to be kind of careful about what we
>  think we mean.
>  ... There is a difference between the capabilities of the system in
>  which the browser finds itself, and those that will be available at
>  application instantiation.
>  ... There needs to be a way to tell what the system capapbilities
>  are even if they're not currently available.
>  ... I may gray out my camera icon if it's being used by another
>  application as a real-time event, but I still need to know that a
>  camera is present.
>  ... When I think of capabilities, I think of what's available on the
>  system, and not what's currently availalb.e
>  ... The question of what are the free resrouces is a different
>  question.
>  ???: I would love to see description of the output devices,
>  speakers, headphones, so you can give feedback about echo problems.
>  anant: One of the points you made is that capabilities is different
>  from what's available, but how would you deal with a webcam that's
>  unplugged?
>  ... Are you suggesting the need for events of some sort, so that
>  browsers can be notified when capabilities change?
>  ... Here's the thing, the class of applications that need that level
>  of detail are the ones that will want to munge around in SDP.
>  ... There are actually two classes of things that we're trying to do
>  today.
>  ... There are web pages and webapps.
>  ... For example, I think it's aboslutely silly to tell Facebook that
>  they can't tell how many cameras you have. They already know
>  everything about you.
>  ... While I agree that capabilities are important for building
>  applications, the class of applications that need that is very, very
>  small.
>  ... Mozilla and others are working on web applications as a distinct
>  idea, that can be installed just like installing a native
>  application.
>  ddruta: I think you need the actual availability of resources.
>  Ted_Hardie: Three unrelated points:
>  ... 1) Whether or not the class of applications that care about this
>  and the class of application that munges SDP really depends on the
>  level of munging.
>  ... The class of application that needs to know how many m-lines you
>  need is different from the kind that wants to know the details of
>  every single codec you support.
>  ... 2) I would be very surprised if people thought navigating to the
>  pokerstars website was the same experience of installing a
>  pokerstars app.
>  ... 3) The perfect is the enemy of the good. If a guy plugs a camera
>  in, and then needs to manually referesh the page for it to show up,
>  before we get a pub-sub system for events.
>  <dom> (getting hardware events is not something difficult by any
>  measure)
>  Ted_Hardie: It's great if it figures this out on its own, but it's
>  not a great shock to a user if he needs to tell the page about it.
>  ... ekr: I've got a situation with 3 monitors and cameras. I say
>  give me a video stream, and it gives me the wrong one. What behavior
>  to you proscribe for the user to get the right camera?
>  anant: The proposal that we have is for the user interface to be
>  able to switch between cameras is something that the browser chrome
>  provides.
>  juberti: Speaking as someone who develops an application that does
>  want to have its fingers in everything, Hangouts probably needs
>  about 1 byte of information.
>  ... A bit for the camera, a bit for the microphone, and some notion
>  of a preferred device.
>  ... I think anant's suggestion that the browser provides the UI for
>  switching cameras is fine.
>  burn: It seems to me that this won't scale.
>  ... If you have a lot of devices, it seems to me trying to put this
>  in the chrome...
>  anant: I think it's exactly the right place. On a Mac, you have a
>  system control panel that tells you what the default camera is.
>  juberti: Even on Windows 7, there's no notion of a default camera.
>  anant: Why do you think the browser is not the place to switch
>  between cameras?
>  burn: If you only need one camera and one microphone, then it's
>  probably fine.
>  juberti: I want to make a telepresence system in a box... with three
>  monitors and three cameras, and that doesn't work if you can only
>  have one camera at a time.
>  burn: Right, the browser isn't the place to decide any arbitrary
>  mapping of devices, so you can decide which camera is camera 1,
>  which camera is camera 2, etc.
>  anant: We could come up with another API so the browser decides
>  which camera shows up in a preview in a given location of the
>  screen.
>  ... We want the ability to lie.
>  ... Even if I do have a web cam, I may just want to stream an AVI
>  file.
>  burn: It puts it completely under user control, what stream is being
>  provided. Interesting.
>  juberti: I really like the idea of having this in the chrome
>  somewhere, because it's going to be static.
>  ... Even in the telepresence scenario, the need to pick the cameras
>  is going to be fairly low.
>  adambe: In the current proposal there is a textbox for selecting a
>  file, in order not to lock people out of applications that require
>  video.
>  ... Another thing is, I think a quite common way to interact with
>  this chrome dialog is you go to a page, it acquires your media
>  devices, you get a UI in the chrome, and it shows a preview and VU
>  meters for your microphones, and you see the camera you want is not
>  connected, you plug it in, and it pops up....
>  ... I don't know, if you need events, and if you plug in a camera
>  and suddenly something happens, I think that may be scary for users.
>  juberti: What applications do we see working well with a
>  pre-recorded video file?
>  adambe: Like a chat application, I could just loop something.
>  juberti: I'm not compelled by this argument.
>  anant: I disagree. We should absolutely let people loop files if
>  they want to.
>  juberti: I think having capabilities bits that are meaningless...
>  anant: Maybe we rename them "has webcam" instead of "has video"...
>  juberti: We keep bringing up the case of plugging in a camera to go
>  make a call, and I think that's an antiquated notion and very much
>  an edge case.
>  ???: If we come up with an API that says "has audio", when we get to
>  smell-o-vision, we're going to be screwed.
>  fluffy: I want to address two different things.
>  ... 1) W.R.T. pluggin in webcams going away...
>  ... My laptop has an incredible thin camera, but on the wall back
>  there is one with a lot of glass.
>  ... I think as we move to HD, people are going to want to use
>  devices that provide a lot higher quality.
>  ... 2) I think that when you're talking about a device with a small
>  amount of screen real-estate, but you have an application that wants
>  to easily be able to switch between front & back...
>  ... I don't see how we're going to get browser chrome that doesn't
>  use up a lot of screen real-estate, but still lets you easily
>  switch.
>  burn: There's a lot of things happening on PCs right now, but we do
>  need to make sure it works for small, mobile devices.
>  ???: I think two bits of information for capabilities is too
>  restrictive.
>  ???: If I have three cameras and I want to write an app that picks
>  the best one, am I going to have to come to the W3C to get a new
>  spec for that?
>  jlennox: For the plugging in the device thing... the use case I
>  think of is, I see who's calling, and I realize I don't want the
>  person in the cube next to me overhearing what they're saying, and I
>  plug in a headset.
>  ... The other thing is for the multiple cameras, I'll probably be
>  using them both in the same browser, even if it's not the same app.
>  anant: The whole fundamental of the web is that APIs are simple, so
>  that JS does not have to worry about what camera is the best. The
>  browser is in a much better position to make this decision.
>  ???: You're saying to me that the only thing I can do is write for
>  the lowest common denominator.
>  anant: Why do you think, if there are three cameras, the browser
>  isn't going to provide you the best one?
>  ???: What if I want to do some 3D thing?
>  jlennox: For front and back there is no best, it depends on what
>  you're doing.
>  jesup: There's some other issues involving capabilities. Talking
>  about the login issue for Google+. What happesn when you're logged
>  into 3 devices on your Google ID, and one of them has a camera, one
>  of them has a mic, and one of them has both.
>  juberti: So the whole point of having capabilities is to give the
>  user some idea that they're going to have a good experience.
>  ... If you fork the call and it goes to one device that has a
>  camera, and one doesn't, that's probably okay.
>  ... It's not perfect, but for example Google routes the call to the
>  device that actually has the camera.
>  ... It's not perfect, but it's goal is to give the user less
>  frustration.
>  jesup: My point is that as you have more of these devices on your
>  hip, they'll always show the ability to do voice and video, even if
>  you're at your desktop which has neither.
>  hta: So, channeling Jim Gettys, of all people, I think we're talking
>  about what is the best camera... I think, anant, that I totally
>  disagree with you.
>  ... Because if I want to answer my phone, the default video I might
>  want is an image that kept just to my face that doesn't show that I
>  didn't put on my pants, that comes from a room security camera that
>  was slightly processed before it get there.
>  ... Which links multiple applications, some of which run in a
>  browser and some which do not.
>  ... The single capability bit of, "Do I have video?" is needed.
>  ... But the richness of what lies behind that answer should not be
>  underestimated.
>  ekr: I'm glad I'm not writing these things, but I think the choices
>  are, you want a small list of do I have a camera, do I have a mic,
>  or I want everything that the hardware can possibly tell me about
>  the device.
>  dom: For any feature, you can make up a use case for it.
>  ... The real question is what do we lose if we give more
>  information?
>  burn: I think the answer [to do we need capabilities] is a very
>  strong yes, but there is the question of what level we need.
>  ???: By my count we have one of five boxes to fill in: some, all, or
>  none, properties: no, and properties: yes. And if it's "none",
>  properties doesn't make sense.
>  burn: I think the answer to this is that it is worth discussing
>  capabilities. Because there's enough use cases that it's worth
>  having the discussion.
>  anant: I think we can eliminate the none option.
>  burn: I think you were the only one who would have said none, so if
>  you're saying that, then I agree with that.
>  dom: I might say the none option does appeal to me, until I get a
>  better picture of the risk.
>  ... Two bits of information is not a lot, but two bits are bits.
>  ... 0 bits in terms of privacy is better than 2 bits.
>  fluffy: I think "having video" is a lot more than 1 bit.
>  ... If you look at the exact time that I plug in my camera and
>  remove my camera, that is likely to be very unique across a large
>  collection of devices.
>  burn: I would just ask, since this is not the IETF, if you're
>  prepared to formally object to more than 0 bits?
>  dom: Certainly not.
>  hta: I would say you have less than half an hour left.
>  burn: This is the second of the major topics.
>  ... Of the things we'll need to think about later is, what is the
>  relationship between capabilties and hints?
>  ... And what is the complexity of that, do you need two bits? do you
>  need more than that?
>  ... I put a quote on here: "Every additional bit of user
>  distinguishing information brings us closer to personal
>  identification by sites."
>  ... The key question is what level and quanitity of capabilities
>  information can be shared?
>  ... In general it would be nice to know what level and quantity of
>  information, but we might want to consider if that depends on the
>  state of the call?
>  ... Is this before the call is accepted, whether any media streams
>  have been requested, after the call has been accepted?
>  ... And what are the kinds of permissions associated with this?
>  ekr: As always we have to start with a threat model. I assume the
>  concern here is the creation of a super-cookie?
>  burn: Yes, without you saying who you are, they figure out who you
>  are.
>  ekr: The way the browser is strucutred now, there is ample
>  opportunity to do this.
>  ... I think that implies operating in multiple modes. If you try to
>  turn off cookies now, the web doesn't work. If you only turn off
>  3rd-party cookies, it barely works.
>  <dom> (I'm browsing with 3rd-party cookies off without that much
>  trouble, actually)
>  ekr: Unless the user has already expressed they're willing to
>  undergo some pain and suffering to avoid creating a super-cookie...
>  ... If the guy's running Tor, then I'm all excited about ways to
>  prevent fingerprinting, but otherwise I think give them all the
>  capabilities they want.
>  <dom> [16]Panopticlick
>   [16] https://panopticlick.eff.org/
>  anant: I want to mention a site called Panopticlick run by the EFF.
>  ... When I visited it, I had 21 bits of identifying information.
>  Give the number of people today, you only need 33 to uniquely
>  identify individuals.
>  ... So every bit we add gets us that much closer to allowing ad
>  networks uniquely identifying who you are without any collusion.
>  burn: When I said a cookie tells them who you are, I meant they can
>  distinguish you from anyone else who's visited your site.
>  anant: The threat that we're trying to tackle is you exposing enough
>  entropy that they can uniquely identify you without sharing
>  information with other websites.
>  ekr: Let's stipulate the browser generates a 128-bit random number
>  at initialization time and sends that to every website in the
>  universe.
>  ... So that allows every site to see that you've visited them over
>  and over again.
>  ... And it allows them, in coordination, to figure out that the same
>  person has visited multiple sites.
>  anant: The risk we're trying to protect against is the guy who finds
>  that you are the only person who bought Smell-o-Vision from this
>  Walmart, which means they can tell who you are without coorindate
>  with any other site.
>  ???: I don't see these as bits that are unique. Audio and video are
>  so prevalent, they don't provide much value.
>  ???: Let's say there's some guy who has 16 cameras attached to his
>  system, that's not 16 bits.
>  anant: It's bits of entropy. For example, looking at the ordering
>  information that fonts are returned, you can figure out what
>  sub-version of the operating system they're using.
>  ... Audio and video may not be two bits, but each time you add more
>  information you're getting closer to 33 bits.
>  juberti: Is this 21 bits counting the user agent or not?
>  anant: Yes.
>  juberti: Can't you already get the OS version, browser version from
>  the UA already?
>  jlennox: Panopticlick claims that I'm the only person who visited
>  their site with my list of plugins.
>  burn: Yeah, some of their results seem unlikely.
>  fluffy: Yeah, I took a brand new Apple with nothing installed and
>  that showed up as unique.
>  ... But you look at what they actually check, and it's like whoa...
>  anant: When you're actively telling the site who you are, none of
>  this is relevant.
>  ... When you go to Facebook and log in with your real name, there's
>  no harm at all.
>  ... If there's some way in which we can tie in... that's one way we
>  can elevate privileges for a site. Another way is installing an app,
>  but just clicking on a URL should not expose this information.
>  ???: This seems like an entirely generic threat to me, and I don't
>  see why WebRTC feels the need to take on this threat by itself.
>  dom: WebRTC is not the only group facing this issue.
>  ... It has come up in the Device APIs WG and the WebApps WG as well.
>  ... I guess the thing is that everyone is quite worried about it,
>  and there's no general solution that is available today.
>  ... One piece though is that we might be uniquely identifiable by
>  Facebook without wanting to tell them that you own 10 monitors, etc.
>  ... I don't think we can simply ignore it, even if we as a group...
>  we'd be very likely to get last call comments on this, but even
>  before that from implementors...
>  ... That doesn't mean we shouldn't play with capabilities and
>  identity, but I don't think we can just ignore this problem and hope
>  for the best.
>  ???: This slide could be, I assume, in almost any working group, if
>  you put a different verb in there.
>  ???2: I'm totally all for privacy, but saying that you have a
>  browser mode that turns off capabilities... is there a problem with
>  that?
>  anant: There is a problem with that. In our experience with Mozilla,
>  preferences do not matter.
>  ... Default preferences matter. 98% of users don't change any knob.
>  ... Firefox is totally extensible, so there'll be a knob to turn it
>  off, but we're discussing what the default is.
>  ???2: People who care about privacy will turn it off.
>  anant: Ordinary people don't understand the issues of privacy. So
>  it's our responsibility as technical people to make reasonable
>  decisions for them.
>  ... Setting sane defaults for the general population is what we're
>  trying to do here.
>  jlennox: Fingerprinting is not the only leakage we have to worry
>  about here.
>  ... Someone mentioned wanting to know whether or not the camera was
>  currently in use...
>  ... That seems like a serious information leakage if someone could
>  tell when I was on a phone call.
>  ... Even if it's not fingerprinting, it's still behavioral tracking.
>  burn: So you mean if you have two websites open, while you're using
>  the camera on one, the other one knows you're using it.
>  ... Would you be okay with having a setting in the browser that
>  disables that?
>  jlennox: I don't change preference either.
>  Matthieu: I would be worried about going to Facebook and them having
>  the exact model of camera I have so they can better serve me ads.
>  ... I do want applications that are allowed to get information that
>  is useful to them, but there is probably a trade-off there.
>  burn: I don't know a technology yet that says only use my
>  information for what I want you to use it for.
>  jesup: There is also the political website example... if someone can
>  use that information to figure out who you are, your browser can be
>  very dangerous to you.
>  burn: People who understand that their life might be in jeopardy,
>  are they likely to change their defaults?
>  jesup: They won't even understand why that's an issue.
>  hkaplan: If you go to a sight like light-reading or related message
>  boards... at work I'm not allowed to post at sites like that, so of
>  course I use a pseudonym.
>  ... I know to click the button that flushes my cookies, clears my
>  cache...
>  ... But I don't want them to know that I'm the same person that logs
>  in as both Hadriel Kaplan and Stalker.
>  ... But as for the site that gets my information in order to better
>  target ads... that's a feature!
>  burn: As for the items on the slide, I don't think we've even
>  addressed half of them.
>  ... I don't think we have a clear consensus.
>  anant: I have a proposal: I think we should expose the minimum
>  amount of information needed to implement something as complex as
>  Google hangout.
>  ... It sounds like we need the audio bit and the video bit and an
>  API to allow the user to flip between sources in Chrome.
>  burn: I like the idea of picking an app or set of applications, but
>  whether Google Hangouts should be the reference...
>  juberti: I'm okay with that choice.
>  ... When you're talking about APIs, are you talking about internal
>  browser APIs, or...?
>  anant: No, not even APIs, but internal browser settings.
>  juberti: I agree with anant's proposal.
> Data Streams API
>  burn: We're moving on. Obviously there's a lot more to discuss.
>  ... So we'll continue the discussion on the mailing list, and on the
>  conference calls as well.
>  <dom> [17]WebRTC Data Streams slides
>   [17]
> http://www.w3.org/2011/04/webrtc/wiki/File:WebRTCDataStreamsIETF82.5.pdf
>  <dom> ScribeNick: dom
>  Justin: Randell talked about the wire format for data streams
>  yesterday
>  ... it raises questions about the requirements
>  ... the core problem we're trying to solve today is to allow to send
>  data for low-latency/high bandwidth needs
>  ... we want support for multiple channels
>  ... [details use cases from slides]
>  ???: there is also a requirement around in-order / not-ordered
>  <JonathanLennox> JonathanLennox was me
>  justin: [details changes since last draft]
>  ... unidirectional data streams make it much easier to deal with
>  multiparty use cases
>  ???: re unidirectional for multicast, if you want to build a full
>  mesh, the number of streams will have to go up with the number of
>  participants
>  scribe: so that makes it somewhat more complicated since you have to
>  deal with adding/removing streams
>  justin: we already do that for mediastreams
>  ... [datastream design slide]
>  ... due to unreliability and unidirectional, we don't have full
>  fidelity with websockets
>  ... but the closer we stick to them, the better
>  ... [datastream and mediastream slide]
>  ... to avoid duplicating APIs, and given their commonality, I'm
>  proposing a basestream class
>  ... only addStream need to be specialized
>  ... ["changes to peerconneciton" slide]
>  Adam: addDataStream() need to return a DataStream object
>  Stefan: since DataStreams are unidirectional, you need @@@
>  Justin: [DataStream API]
>  ... there is currently no bit to distinguish in-order/not-in-order
>  Eric: I assume the streams are in a single SCTP connection
>  Justin: yes
>  ... Is there a max number of channels in a single association?
>  Magnus: in the order of the 64K, so probably not a pb
>  Justing: [DataStream API slide]
>  ... MTU is set in maxMessageSize
>  ... [Basic Flow slide]
>  ... [Full Example slide]
>  Magnus: the mime type needs to come after the protocol (?)
>  ... in the SDP example
>  Harald: why have you picked on signalling these channels, instead of
>  relying on channel events from the implementation
>  Justin: will that you give you the label? The reliability?
>  Harald: it will tell you the channel number
>  Justin: I have another slide on signalling vs non-signalling
>  ... [multiparty example slide]
>  ... [open issues]
>  ... we've had the discussion on the list for a simple method as
>  proposed by Stefan
>  ... Want to get sure that the group agrees we need the more complex
>  API
>  ... ["CC" stands for congestion control]
>  ???: on congestion control, I think it would be a dramatic mistake
>  to use bandwidth to signal packet drops
>  Justin: getting feedback on the congestion control state can help
>  adjust it
>  Randell: feedback on available bandwidth can be used to make a
>  number of adjustments
>  ... but not sure about feedback on specific packet drop
>  ... but feedback on congestion control in general seems useful
>  Magnus: I don't think leaky buckets is a good model for this
>  ... what matters is the current state being acked by the other side
>  Spencer: I wouldn't mind talking about the congestion control stuff
>  ... application-level congestion control is really hard
>  ... I would encourage to think hard about how much applications
>  should be doing
>  Magnus: the only thing you can do is to try to adapt to the
>  congestion
>  ... you can't direct congestion control itself
>  ... but adapt the transmitted data for instance
>  @@@: moving back from congestion control to the signalling issue
>  scribe: I do think it's worth considering whether or not these
>  channel numbers can be used
>  ... one thing I remember from the data APIs we discussed yesterday
>  is that they're very application-specific
>  ... they're not going to a lot of filters
>  ... they could go through a central muxer (?)
>  ... There is some thoughts to be given here; labels may have a place
>  ... not sure about reliable/non-reliable  I think that should be
>  available directly from the SDP stack
>  ... the only remaining bit that seems to need signalling here is the
>  label
>  ... there is some use cases I thought of where you may have a very
>  high volume of channels coming and going
>  ... e.g. if you're acting as a proxy for the other person you're
>  talking to
>  ... you may have a very high number of channels closing and opening
>  ... or if you're doing a backup
>  ... if you make it expensive to open and close connections
>  ... the application developers will start implementing on top of a
>  single connection
>  Justin: it's a good thought exercise to go through to identify which
>  use cases wouldn't work
>  ... I have a specific use case in mind that is hard to solve without
>  labels
>  @@@: the description could be done via a separate data channel
>  (rather than via the signalling channel)
>  scribe: given that a bunch of applications wouldn't need this
>  Harald: signalling, I would like to study a case - I don't
>  understand why you want it
>  ... re congestion feedback, if you've played WoW, you've heard "Lag!
>  Lag! Lag!"
>  ... not communication transport information to the application level
>  has been a mistake we shouldn't repeat
>  Jonathan: some examples for reliable/non-reliable
>  ... mouse pointer: you want in-order, but not necessarily reliable
>  ... for file transfer, you want reliable, but doesn't need to be
>  in-order
>  ???: [help, I missed that]
>  ->
>  [18]http://www.w3.org/2011/04/webrtc/wiki/File:Aligned_Data_API.pdf
>  Aligned Data API
>   [18]
> http://www.w3.org/2011/04/webrtc/wiki/File:Aligned_Data_API.pdf
>  <JonathanLennox> It was asking about whether push notifications
>  should be aligned with data channels, either in technology or in
>  API. Justin said he hadn't thought about it at all.
>  Stefan: I drafted a proposal to offer a simplified data API aligned
>  with other APIs
>  ... [Basic Proposal slide]
>  ... [Changes to PeerConnection slide]
>  ... [postMessage() spec extract]
>  Justin: would this be reliable or unreliable?
>  Stefan: only reliable as a starting point
>  ... [examples slide]
>  ... based on feedback, we could add DataOptions for reliability,
>  priority
>  Ted: it seems that you want to set this up for every PeerConnection
>  ... so you would create a data channel even if you don't have use
>  for it
>  ... If so, I don't think many enterprise folks would be too happy
>  for that
>  ... because you've created an encrypted channels you don't know what
>  it is used for
>  ... I'm not sure what the benefit is
>  Stefan: the point is to align it with web sockets
>  Ted: I don't think that's quite as motivated as it might be
>  Stefan: it could be simple to change the model to make the stream
>  Anant: what does it bring over web sockets?
>  Stefan: it's peer-to-peer
>  Anant: I think not having unreliable data is a killer
>  Harald: if the IETF side concludes that it will use a protocol that
>  has support for multiple channels with congestion control and
>  optional reliability
>  ... it would be a shame not to take advantage of it simply for
>  saving specification work
>  ... given that need for it has been identified in the requirements
>  document, it seems to me we should just go ahead with it
>  Stefan: it's not clear that needs have been so well identified
>  ... also, the most advanced tool that Web developers can use today
>  is Web Sockets
>  @@@: My discussions with people in Mozilla who have contacts with
>  the Web Game writing community
>  scribe: and they all want this
>  <hta> @@@ = Randell Jesup
>  scribe: they're very interested in not having to implement
>  not-reliable/reliable, multiple channels
>  ... they clearly need channels with different characteristics
>  Stefan: I think the conclusion is quite clear that we'll go for the
>  DataStream proposal
>  ... [reads action items he noted, that will be sent later to the
>  list]
>  Harald: for Data API, the next iteration is to integrate that in the
>  spec
>  Justin: and once it's in the spec, we can implement it :)
Received on Friday, 10 February 2012 23:44:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC