RTCDataChannel.negotiated - Web APIs
the read-only rtcdatachannel property negotiated indicates whether the rtcdatachannel's connection was negotiated by the web app (true) or by the webrtc layer (false). the default is false. see creating a data channel in using webrtc data channels for further information about this property. syntax var negotiated = adatachannel.negotiated; value true if the rtcdatachannel's connection was negotiated by the web app itself; false if the negotiation was handled by the webrtc layer. the default is false. example the code snippet below checks the value of negotiated; if it's true, a function called shutdownremotechannel() is called with the channel's id; presumably this would be implemented to transmit a shutdown signal to the remote peer prior to terminating the connection. if (datachannel.ne...
...hannel() is called with the channel's id; presumably this would be implemented to transmit a shutdown signal to the remote peer prior to terminating the connection. if (datachannel.negotiated) { shutdownremotechannel(datachannel.id); } specifications specification status comment webrtc 1.0: real-time communication between browsersthe definition of 'rtcdatachannel.negotiated' in that specification. candidate recommendation initial specification. ...

Index - Web APIs
xretransmits experimental, needsexample, property, rtcdatachannel, read-only, reference, webrtc, maxretransmits the read-only rtcdatachannel property maxretransmits returns the maximum number of times the browser should try to retransmit a message before giving up, as set when the data channel was created, or null, which indicates that there is no maximum. 3237 rtcdatachannel.negotiated networking, property, rtcdatachannel, read-only, reference, webrtc, webrtc api, data, datachannel, negotiated the read-only rtcdatachannel property negotiated indicates whether the rtcdatachannel's connection was negotiated by the web app (true) or by the webrtc layer (false). 3238 rtcdatachannel.onbufferedamountlow event handler, experimental, networking, property, rtcda...
...rting a new webrtc connection to a remote peer. 3417 rtcpeerconnection.currentlocaldescription api, media, property, rtcpeerconnection, read-only, reference, sdp, webrtc, currentlocalconnection the read-only property rtcpeerconnection.currentlocaldescription returns an rtcsessiondescription object describing the local end of the connection as it was most recently successfully negotiated since the last time the rtcpeerconnection finished negotiating and connecting to a remote peer. also included is a list of any ice candidates that may already have been generated by the ice agent since the offer or answer represented by the description was first instantiated. 3418 rtcpeerconnection.currentremotedescription api, media, property, rtcpeerconnection, read-only, refere...
...by the description was first instantiated. 3418 rtcpeerconnection.currentremotedescription api, media, property, rtcpeerconnection, read-only, reference, sdp, webrtc, currentremotedescription the read-only property rtcpeerconnection.currentremotedescription returns an rtcsessiondescription object describing the remote end of the connection as it was most recently successfully negotiated since the last time the rtcpeerconnection finished negotiating and connecting to a remote peer. also included is a list of any ice candidates that may already have been generated by the ice agent since the offer or answer represented by the description was first instantiated. 3419 rtcpeerconnection.defaulticeservers experimental, ice, property, rtcpeerconnection, reference, webrtc,...
...And 4 more matches

RTCPeerConnection - Web APIs
also included is a list of any ice candidates that may already have been generated by the ice agent since the offer or answer represented by the description was first instantiated.currentremotedescription read only the read-only property rtcpeerconnection.currentremotedescription returns an rtcsession...
...also included is a list of any ice candidates that may already have been generated by the ice agent since the offer or answer represented by the description was first instantiated.getdefaulticeservers() the getdefaulticeservers() method of the rtcpeerconnection interface returns an array of objects ba...
...motedescription returns a rtcsessiondescription describing the session (which includes configuration and media information) for the remote end of the connection. if this hasn't been set yet, this is null.sctp the read-only sctp property on the rtcpeerconnection interface returns an rtcsctptransport describing the sctp transport over which sctp data is being sent and received. if sctp hasn't been negotiated, this value is null.signalingstate read only the read-only signalingstate property on the rtcpeerconnection interface returns one of the string values specified by the rtcsignalingstate enum; these values describe the state of the signaling process on the local end of the connection while connecting or reconnecting to another peer. see signaling in lifetime of a webrtc session for more details ab...
...And 2 more matches

NSS 3.12.6 release notes
rver or client does not support safe renegotiation. the default setting for this option is false. these options can also be set with the following ssl options: ssloptions.enablerenegotiation ssloptions.requiresafenegotiation new pseudo cipher suite value: tls_empty_renegotiation_info_scsv (cannot be negotiated) tls server name indication for servers tls server name indication (sni) for servers is almost fully implemented in nss 3.12.6. see bug 360421 for details. note: the tls server name indication for clients is already fully implemented in nss. new functions for sni (see ssl.
...ssl_sni_current_config_is_used: libssl must use the default cert and key. ssl_sni_send_alert: libssl must send the "unrecognized_name" alert. ssl_snisocketconfighook ssl_reconfigfd ssl_configserversessionidcachewithopt ssl_settrustanchors ssl_getnegotiatedhostinfo new enum for sni: sslsninametype (see sslt.h) new functions in cert.h certdistnames: duplicate distinguished name array. cert_distnamesfromcertlist: generate an array of distinguish...
... cert_cacheocspresponsefromsidechannel: this function is intended for use when ocsp responses are provided via a side-channel, i.e. tls ocsp stapling (a.k.a. the status_request extension). ...
... bug 542538: nss: add function for recording ocsp stapled replies bug 544191: use system zlib on mac os x bug 544584: segmentation fault when enumerating the nss database bug 544586: various nss-sy...

Using WebRTC data channels - Web APIs
ransport and write your own code to signal to the other peer that it needs to connect to the new channel. let's look at each of these cases, starting with the first, which is the most common. automatic negotiation often, you can allow the peer connection to handle negotiating the rtcdatachannel connection for you. to do this, simply call createdatachannel() without specifying a value for the negotiated property, or specifying the property with a value of false. this will automatically trigger the rtcpeerconnection to handle the negotiations for you, causing the remote peer to create a data channel and linking the two together across the network. the rtcdatachannel object is returned immediately by createdatachannel(); you can tell when the connection has been made successfully by watching for ...
...t to be sent to the rtcdatachannel. let datachannel = pc.createdatachannel("myapp channel"); datachannel.addeventlistener("open", (event) => { begintransmission(datachannel); }); manual negotiation to manually negotiate the data channel connection, you need to first create a new rtcdatachannel object using the createdatachannel() method on the rtcpeerconnection, specifying in the options a negotiated property set to true. this signals to the peer connection to not attempt to negotiate the channel on your behalf. then negotiate the connection out-of-band, using a web server or other means. this process should signal to the remote peer that it should create its own rtcdatachannel with the negotiated property also set to true, using the same id. this will link the two objects across the rtcpeer...
... to negotiate the channel on your behalf. then negotiate the connection out-of-band, using a web server or other means. this process should signal to the remote peer that it should create its own rtcdatachannel with the negotiated property also set to true, using the same id. this will link the two objects across the rtcpeerconnection. let datachannel = pc.createdatachannel("myapp channel", { negotiated: true }); datachannel.addeventlistener("open", (event) => { begintransmission(datachannel); }); requestremotechannel(datachannel.id); in this code snippet, the channel is created with negotiated set to true, then a function called requestremotechannel() is used to trigger negotiation, to create a remote channel with the same id as the local channel. doing this lets you create data channels ...

L20n Javascript API
e to negotiate against and freeze the context instance. when a context instance is frozen, no more resources can be added or linked. all io related to fetching the resource files takes place when a context instance freezes. when all resources have been fetched, parsed and compiled, the context instance will emit a ready event. the final list of locales supported by the context instance will be negotiated asynchronously by the negotiator registered by registerlocalenegotiator. ctx.requestlocales('pl'); ctx.requestlocales('fr-ca', 'fr'); if requestedlocales argument list is empty or undefined, the default locale from registerlocales will be used. ctx.requestlocales('pl'); if registerlocales hasn't been called, the special i-default locale is used, which means that the following minima...
...nce. var ctx = l20n.getcontext(); ctx.addresource('<hello "hello, world!">'); ctx.requestlocales(); requestlocales can be called multiple times after the context instance emitted the ready event, in order to change the current language fallback chain, for instance if requested by the user. ctx.supportedlocales a read-only property which holds the current fallback chain of locales which was negotiated between all the available locales, the default locale and the user's preferred locales. ctx.registerlocales('en-us', ['en-us', 'fr', 'pl']); ctx.requestlocales('fr-ca', 'fr'); ctx.ready(function() { // ctx.supportedlocales == ['fr']; }); ctx.addresource(text: string) add a string as the content of a resource to the context instance. the resource is added to all registered locales. ctx.a...

NSS 3.15.2 release notes
_3_15_2_rtm/src/ security advisories the following security-relevant bugs have been resolved in nss 3.15.2. users are encouraged to upgrade immediately. bug 894370 - (cve-2013-1739) avoid uninitialized data read in the event of a decryption failure. new in nss 3.15.2 new functionality aes-gcm ciphersuites: aes-gcm cipher suite (rfc 5288 and rfc 5289) support has been added when tls 1.2 is negotiated. specifically, the following cipher suites are now supported: tls_ecdhe_ecdsa_with_aes_128_gcm_sha256 tls_ecdhe_rsa_with_aes_128_gcm_sha256 tls_dhe_rsa_with_aes_128_gcm_sha256 tls_rsa_with_aes_128_gcm_sha256 new functions pk11_cipherfinal has been introduced, which is a simple alias for pk11_digestfinal. new types no new types have been introduced. new pkcs #...
...rt for aes-gcm ciphersuites that use the sha-256 prf bug 663313 - md2, md4, and md5 signatures are no longer accepted for ocsp or crls, consistent with their handling for general certificate signatures. bug 884178 - add pk11_cipherfinal macro bugs fixed in nss 3.15.2 bug 734007 - sizeof() used incorrectly bug 900971 - nssutil_readsecmoddb() leaks memory bug 681839 - allow ssl_handshakenegotiatedextension to be called before the handshake is finished. bug 848384 - deprecate the ssl cipher policy code, as it's no longer relevant. it is no longer necessary to call nss_setdomesticpolicy because all cipher suites are now allowed by default. a complete list of all bugs resolved in this release can be obtained at https://bugzilla.mozilla.org/buglist.cgi?resolution=fixed&classification=compon...

RTCDataChannel.id - Web APIs
each rtcpeerconnection can therefore have up to a theoretical maximum of 65,534 data channels on it, although the actual maximum may vary from browser to browser. in early versions of the webrtc specification, this property's name was stream. ...
... each rtcpeerconnection can therefore have up to a theoretical maximum of 65,534 data channels on it, although the actual maximum may vary from browser to browser. in early versions of the webrtc specification, this property's name was stream. ...

RTCDataChannel.stream - Web APIs
this property has been replaced with the rtcdatachannel.id property. ...
... this property has been replaced with the rtcdatachannel.id property. ...

RTCPeerConnection.createDataChannel() - Web APIs
transmit a message which fails the first time in unreliable mode. while this value is a16-bit unsigned number, each user agent may clamp it to whatever maximum it deems appropriate. default: null. protocol optional the name of the sub-protocol being used on the rtcdatachannel, if any; otherwise, the empty string (""). default: empty string, "". this string may not be longer than 65,535 bytes. negotiated optional by default (false), data channels are negotiated in-band, where one side calls createdatachannel, and the other side listens to the rtcdatachannelevent event using the ondatachannel eventhandler . alternatively (true), they can be negotiated out of-band, where both sides call createdatachannel with an agreed-upon id. default: false. id optional an 16-bit numeric id for the channel; pe...
... specifications specification status comment webrtc 1.0: real-time communication between browsersthe definitio...

Writing WebSocket servers - Web APIs
the server may listen on any port it chooses, but if it chooses any port other than 80 or 443, it may have problems with firewalls and/or proxies. browsers generally require a secure connection for websockets, although they may offer an exception for local devices. the handshake is the "web" in websockets. it's the bridge from http to websockets. in the handshake, details of the connection are negotiated, and either party can back out before completion if the terms are unfavorable. the server must be careful to understand everything the client asks for, otherwise security issues can occur. tip: the request-uri (/chat here) has no defined meaning in the spec. so, many people use it to let one server handle multiple websocket applications. for example, example.com/chat could invoke a multiuser c...
...g handshake (detailed in section 5.5.1). upon receiving such a frame, the other peer sends a close frame in response. the first peer then closes the connection. any further data received after closing of connection is then discarded. miscellaneous websocket codes, extensions, subprotocols, etc. are registered at the iana websocket protocol registry. websocket extensions and subprotocols are negotiated via headers during the handshake. sometimes extensions and subprotocols very similar, but there is a clear distinction. extensions control the websocket frame and modify the payload, while subprotocols structure the websocket payload and never modify anything. extensions are optional and generalized (like compression); subprotocols are mandatory and localized (like ones for chat and for mmorpg ga...

Transport Layer Security - Web security
ent and the server, in order to prevent it from being read and interpreted by unauthorized parties. integrity tls ensures that between encrypting, transmitting, and decrypting the data, no information is lost, damaged, tampered with, or falsified. a tls connection starts with a handshake phase where a client and server agree on a shared secret and important parameters, like cipher suites, are negotiated. ...
...mpered with, or falsified. a tls connection starts with a handshake phase where a client and server agree on a shared secret and important parameters, like cipher suites, are negotiated. once parameters and a data exchange mode where application data, such http, is exchanged. cipher suites the primary parameters that the tls handshake negotiates is a cipher suite. in tls 1.2 and earlier, the negotiated cipher suite includes a set of cryptographic algorithms that together provide the negotiation of the shared secret, the means by which a server is authenticated, and the method that will be used to encrypt data. the cipher suite in tls 1.3 primarily governs the encryption of data, separate negotiation methods are used for key agreement and authentication. different software might use different ...

CSS3 - Archive of obsolete content
onal notation to describe the directionality of the image (rtl or ltr), allowing for bidi-sensitive images. the image-orientation property by adding the keyword from-image, allowing to follow exif data stored into images to be considered. adds: the image-set() functional notation to allow the definition to equivalent images at different resolution allowing for resolution-negotiated selection of images. the element() functional notation allowing the use of part of the page as image. the cross-fade() functional notation allowing to refer to intermediate images when transitioning between two images and defines the interpolation between two images. the conic-gradient() and repeating-conic-gradient() functional notation describing a new type of gradient. the ...

Integrated Authentication
f ntlmv2/lmv2. <i>this document is incomplete ...</i> flow diagram the diagram below shows how various components interact. configuration by default, mozilla rejects all spnego challenges from a web server. this is to protect the user from the possibility of dns-spoofing being used to stage a man-in-the-middle exploit (see bug 17578 for more info). moreover, with windows clients ntlm may be negotiated as the authentication protocol. so, it is paramount that the browser does not freely exchange ntlm user credentials with any server that requests them. the ntlm response includes a hash of the user's logon credentials. on older versions of windows this hash is computed using a relatively weak algorithm (see hertel for more info on ntlm authentication). mozilla currently supports a whitelist of s...

NSS 3.15 release notes
ocitem, which is now declared as obsolete. support for single-operation (eg: not multi-part) symmetric key encryption and decryption, via pk11_encrypt and pk11_decrypt. certutil has been updated to support creating name constraints extensions. new functions in ssl.h ssl_peerstapledocspresponse - returns the server's stapled ocsp response, when used with a tls client socket that negotiated the status_request extension. ssl_setstapledocspresponses - set's a stapled ocsp response for a tls server socket to return when clients send the status_request extension. in ocsp.h cert_postocsprequest - primarily intended for testing, permits the sending and receiving of raw ocsp request/responses. in secpkcs7.h sec_pkcs7verifydetachedsignatureatt...