On Tue, 2011-03-15 at 21:06 +0100, Hay (Husky) wrote:
> 3) 'Data blocks' in a
Ok, firstly let me just say that I'm thrilled about the peer to peer
stuff moving forward, great work Ian. I wish I had a little more time to
get stuck into this now and read the specs a bit more thoroughly, but
I'll try to reply to all your comments that I generated. (Amazingly
รถ still seems t
On 2011-03-18 15:02, Lachlan Hunt wrote:
On 2011-03-18 05:45, Ian Hickson wrote:
On Mon, 24 Jan 2011, Anne van Kesteren wrote:
...
audio.src = blob
(The src content attribute would then be something like
"about:objecturl".)
Could you elaborate on this plan?
... we avoid the unnecessary ove
Is X3DOM an example of solution to what you are trying to do? They embed
hierarchical data directly in HTML docs through namespaces and have
JavaScript use that data
http://www.x3dom.org/
I believe Angular does this as well.
http://angularjs.org/
On Wed, Mar 23, 2011 at 1:36 AM, Robert O'Callahan wrote:
> So it has valid use cases after all?
I always felt it had valid use-cases in *some* form -- namely, some
authors want conforming content, which means no , while some
authors want markup that will work in crippled HTML processors like
Bla
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
This is a well-known and well-analyzed encryption format, with
reasonably known security properties and library support (from libraries
that already have to be included in order to support audio/vide
On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
So, the salt and the nonce play different roles. The salt is to make
sure the message appears random if you haven't read the spec (and so
don't know the salt). The nonce is to prevent the attacker from
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
> On 03/18/11 21:19, Glenn Maynard wrote:
> > On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
> >
> > > So, the salt and the nonce play different roles. The salt is to make
> > > sure the message appears random if you haven't read the spec (and so
On 03/23/11 23:43, Ian Hickson wrote:
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
So, the salt and the nonce play different roles. The salt is to make
sure the message appears random if you haven't
On Wed, Mar 23, 2011 at 6:25 PM, Harald Alvestrand wrote:
> The STUN server is used to obtain your own "public" IP address, for
> constructing candidate lists.
> The STUN server is not involved in the ICE handshake.
>
The STUN server is not. I believe the STUN *protocol* (packet format),
however
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
I'd go one further... why not DTLS-SRTP for the media and DTLS with some
other header shim for the data messages?
In particular, there are significa
On 3/23/2011 3:57 PM, Harald Alvestrand wrote:
I don't think such an attack is possible; there is no mechanism in ICE
for changing the destination IP address without a new handshake.
The potential attack we can't avoid is that a hostile webapp, possibly
with the help of a hostile STUN server
On 03/24/11 01:13, Matthew Kaufman wrote:
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
I'd go one further... why not DTLS-SRTP for the media and DTLS with
some other header shim for the data mes
I'm studying some of the feedback raised over the past few months
regarding history.pushState() and related APIs, in particular in the
context of applying these changes to the spec:
http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/
One of the differences between the spec an
On 3/23/2011 5:22 PM, Harald Alvestrand wrote:
On 03/24/11 01:13, Matthew Kaufman wrote:
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
I'd go one further... why not DTLS-SRTP for the media and DT
Ok. It seems the best solution is to just remove the "suffering from being
too long" state and simply require that authors not let authors enter
values longer than the maxlength. Right?
I agree removing tooLong validity.
Google Chrome 10 has the interactive validation, and is causing some
c
Hi all,
Usually, when the user is using the keyboard to extend or move the
selection in a document, the result of the keyboard commands vary
depending on the underlying platform.
For example, on Windows, word selection "eats spaces" in between words.
That is, if you have "f|oo bar" (the pip
Does that cover the case where multiple characters can be composed to single
character?
I'm thinking the case where undetermined text in CJK input methods tends to be
longer and may be shortened once determined, but there may be more cases where
text gets shorter as you type.
Regards,
Koji
O
> I always felt it had valid use-cases in *some* form -- namely, some
> authors want conforming content, which means no , while some
> authors want markup that will work in crippled HTML processors like
> Blackberry's e-mail client, which means they want . The only
> question was whether there was
Hi,
the EventSource specification states the current content-type header
should match the string "text/event-stream". However following some
bugs opened inside the WebKit project [1], we relaxed the content-type
check to ignore any specified charset as it confused developers and
can potentially br
On Wed, 23 Mar 2011, Julien Chaffraix wrote:
>
> the EventSource specification states the current content-type header
> should match the string "text/event-stream". However following some
> bugs opened inside the WebKit project [1], we relaxed the content-type
> check to ignore any specified chars
21 matches
Mail list logo
