Binding Devices and Control Points as a Resource

Once the secure stream has been negotiated for the UCCD or UCC-CP with the UPnP cloud server (UCS) it will send an XMPP <bind> notification as indicated in the example above where:

If the binding resource is a UCCD it shall bind with a resourcepart as the ordered concatenation of the value of the <deviceType> and the value of the <UDN> separated by a ":" either

resourcepart = urn:schemas-upnp-

org:device:deviceType:ver:uuid:device-UUID or

resourcepart = urn:domain-name:device:deviceType:ver:uuid:device-UUID

• If the binding resource is a UCC-CP it shall bind with a resourcepart as either: o the ordered concatenation of the value of urn:schemas-upnp-org:cloud-1-

0:ControlPoint:ver: and either the value of control point <ID> as defined in DeviceProtection Service [DP] if DeviceProtection Service is implemented , that is, resourcepart = urn:schemas-upnp-org:cloud-1-0:ControlPoint:ver:<ID> or

o a UUID value meeting the same requirements as the device-UUID that is, resourcepart = urn:schemas-upnp-org:cloud-1-0:ControlPoint:ver:uuid

For UCA 1.0, the value of the control point version ver is "1".

Continuing the example from above, upon receiving the bind notification, the UCCD "MediaServer:4" will now bind as:

[email protected]/urn:schemas-upnp-org:device-1-

1:MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950

by sending an <iq> bind request as follows: C:[email protected]/urn:schemas-upnp- org:device:MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950 <iq to="mycloud.org" from="[email protected]" type="set" id="yhc13a95" <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/> <resource> urn:schemas-upnp-org:device:MediaServer:4: uuid:e70e9d0e-d9eb-4748-b163-636a323e7950 </resource> </bind> </iq>

Note, that the value of the iq@id attribute is determined by the endpoint (usually a UCS)15_. A UCS shall accept a conforming request as a new resource with the response:

UCS:mycloud.org <iq to="[email protected] from="mycloud.org" type="result" id="yhc13a95" <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/> <jid>[email protected]/urn:schemas-upnp-org:device: MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950</jid> </bind> </iq>

Error messages received prior to resource binding shall conform to standard XMPP messages as defined in [RFC-6120] and are not considered a UCA error.

Note that a properly implemented UCCD or UCC-CP should not create a resource uniqueness conflict as described in section 7.7.2.2 [RFC-6120], that is uniqueness is guaranteed between all UCCD and UCC-CP resources. A UCS should not attempt to change the name of a requested resource, if it does, the UCCD or UCC-CP requesting the resource bind shall disconnect the stream and try to reconnect according to standard XMPP procedures. A UCCD or UCC-CP shall not accept an XMPP bind that does not conform to its advertised as described above..

Upon a successful bind, the MediaServer:4 UCCD is now connected with its own globally unique fullJID . This is the UCCD cloud address. Note, a UCCD is allowed to have multiple cloud addresses. UCCD:[email protected]/urn:schemas-upnp- org:device:MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950 <iq id="yhc95a13" from="[email protected]/urn:schemas-upnp-org:device:MediaServer:4: uuid:e70e9d0e-d9eb-4748-b163-636a323e7950" to="[email protected]" type="set" <query xmlns="jabber:iq:roster"> <item jid="[email protected]/urn:schemas-upnp-org:device: MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950" name="jeffrey MediaServer 4 on cell"/>

</query> </iq> UCS:mycloud.org <iq id="yhc95a13" to="[email protected]/urn:schemas-upnp-org:device: MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950" from="mycloud.org" type="result">

<query xmlns="jabber:iq:roster" ver="ver1">

<item jid="[email protected]/urn:schemas-upnp-org:device:

MediaServer:4:uuid:e70e9d0e-d9eb-4748-b163-636a323e7950" name="jeffrey MediaServer 4 on cell"/>

</query> </iq>

15 id values in the examples are not randomized or sequenced, as is common practice, for illustration purposes only.

C.5.4.1 Limitations on stanza redirection.

In some cases, XMPP allows for the redirection of stanzas to an alternative "available" resource (see [RFC-6120] section 10.5.4) when a full JID matching the "to" attribute is not "available". For example, a message of type 4 intended for jeffrey's MediaRender (which is "unavailable") could be redirected to jeffey's MediaServer (which is "available"). For UCA communications this is prohibited as follows:

UCCDs and UCC-CPs shall ignore any received stanza that does not have a "from" attribute with a value compliant to a UCA resource as defined above with the following exceptions: • The stanza is a response to a UCCD or UCC-CP request to the UCS or affiliated service

(such as PubSub). Note that the UCCD or UCC-CP should check the stanza @id attribute to confirm.

• The stanza is a notification from the UCS or affiliated service.

• The stanza is a message specifically identified in this specification indicating the allowed override of the prohibition.

A UCS should refrain from redirecting valid UCA messages sent to an "unavailable" UCA resource to an "available" UCA resource and instead send appropriate error messages as described in [RFC-6120].

Note that UCCDs and UCC-CPs are allowed to be combined with other applications that share a common XMPP interface, such as "chat". However, non-UCA stanzas should, instead be sent to the bare JID and resource priority used for any additional routing. Figure C-6 illustrates these two scenarios. In case 1, a MediaServer sends a UCA stanza to an "unavailable" MediaRender. Instead of delivering the stanza to the "available" MediaServer or UCC-CP the appropriate error is returned. In case 2, a non-UCA stanza addressed to the bare JID is sent and delivered to the "available" resource with the highest priority, in this case Jeffrey's UCC-CP; in other terms, UCCDs and UCC-CPs should ignore stanzas of type="chat" unless a chat interface is provided.

C.5.4.2 Handling resource priority

The use of priority in UCCDs and UCC-CPs is allowed in UCA, however its behavior is not guaranteed since XMPP allows a server to override requested priority as described below. From [RFC-6121] section 4.7.2.3

The client's server MAY override the priority value provided by the client (e.g.

in order to impose a message handling rule of delivering a message intended for the account's bare JID to all of the account's available resources). If the server does so

it MUST communicate the modified priority value when it echoes the client's presence back to itself and sends the presence notification to the user's contacts (because this modified priority value is typically the default value of zero communicating the modified priority value can be done by not including the <priority/> child element).

However, it is suggested that UCS recognize the following recommended priorities for UCCDs and UCC-CPs:

UCCDs with no additional XMPP features: priority range of [-100 to -33]. UCCDs with additional XMPP features: priority range of [ 1 to 66]. UCC-CPs with no additional XMPP features: priority range of [ -66 to -1]. UCC-CPS with additional XMPP feature: priority range of [ 33 to 100].