From 68f03fc9b1c6b8d0baf4115c05bc16fb87c7ff02 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 9 Mar 2009 17:47:04 +0000 Subject: [PATCH] 0.16 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2856 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0177.xml | 50 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 36 insertions(+), 14 deletions(-) diff --git a/xep-0177.xml b/xep-0177.xml index ea09e0b4..2ddb9079 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -27,6 +27,12 @@ &scottlu; &hildjj; &seanegan; + + 0.16 + 2009-03-09 + psa +

Minor changes to track modifications to XEP-0166; updated security considerations for consistency with XEP-0176.

 + 0.15 2009-02-11 @@ -180,10 +186,10 @@ INITIATOR RESPONDER

In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace &VNOTE;, which MUST This is required to avoid a round trip and help expedite the negotiation. include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'id' attributes of the &CANDIDATE; element. The &TRANSPORT; element MAY include more than one &CANDIDATE; element (typically one for RTP and another for RTCP).

- @@ -228,17 +234,17 @@ INITIATOR RESPONDER

As described in XEP-0166, to acknowledge the session initiation request, the responder returns an IQ-result:

]]> -

As soon as the responding user agrees to proceed with the session, the responding client MUST send a Jingle session-accept to the initiator. This session-accept message MAY include one or more candidates generated by the responder.

+

Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message MUST contain a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace, which SHOULD in turn contain one &CANDIDATE; element for each Raw UDP candidate generated by or known to the responder.

- The initiator then acknowledges the session acceptance.

]]> @@ -278,10 +284,10 @@ INITIATOR RESPONDER

An implementation SHOULD enforce a timeout on receipt of media, such that if no media is received from the other party within a reasonable period of time, the implementation will consider the session to have failed and therefore send to the other party a Jingle "session-terminate" action with a reason code of <timeout/>.

- @@ -292,7 +298,7 @@ INITIATOR RESPONDER

The other party then acknowledges termination of the session.

]]> @@ -300,10 +306,10 @@ INITIATOR RESPONDER -

If an entity supports the Jingle Raw UDP transport, it MUST return a feature of "urn:xmpp:jingle:transports:raw-udp:1" &VNOTE; in response to &xep0030; information requests.

+

To advertise its support for the Jingle ICE-UDP Transport Method, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:transports:raw-udp:1" for this version and "urn:xmpp:jingle:transports:raw-udp:0" for the previous version &VNOTE;.

@@ -311,11 +317,16 @@ INITIATOR RESPONDER ]]> + + + + + ]]> @@ -323,7 +334,18 @@ INITIATOR RESPONDER -

In order to secure the data stream that is negotiated via the Jingle Raw UDP transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding RTP sessions, refer to XEP-0167).

+ +

By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:

+
    +
  1. The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).
    2. +
  2. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in RFC 3921.
    3. +
  3. The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.
    4. +
+ + +

A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over a UDP association, such as those described in &xtls;.

+

Application types that use the Jingle Raw UDP transport method MAY also define their own application-specific encryption methods, such as the Secure Real-time Transport Protocol (SRTP) for RTP exchanges as described in &xep0167;.

+