%ents; ]>
Rayo Fax This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for sending and receiving faxcimilies via a call under the control of a Rayo client. &LEGALNOTICE; 0342 Deferred Standards Track Standards Council XMPP Core XEP-0327 Rayo XEP-0341 Rayo CPA NOT_YET_ASSIGNED Ben Langfeld ben@langfeld.me ben@langfeld.me http://langfeld.me 0.3.1 2018-11-03 pep Fix a bunch of typos, batch-style. 0.3 2017-09-11 XEP Editor (jwi) Defer due to lack of activity. 0.2 2014-03-13 bl

Specify dependencies correctly; clearer wording on security considerations; proper linking.

 0.1 2014-01-14 psa

Initial published version approved by the XMPP Council.

 0.0.1 2013-10-02 bl

First draft.

Rayo allows for the third-party control of media sessions such as telephone calls. A common requirement in telephony applications providing backward compatability with legacy systems is to support sending and receiving faxes. This specification extends the core Rayo specification, to describe a protocol for this use case.

This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise.

A Rayo client may utilise Rayo CPA to establish a fax CNG tone before initiating fax receipt using the receivefax component described below.

The receivefax component accepts a fax from a caller, stores it, and makes it available to Rayo clients. The component is created using a <receivefax/> command.

]]>

The server MUST validate that it has apropriate resources/mechanisms to receive the fax before acknowledging the component creation.

The receivefax component does not implement any intermediary commands.

The receivefax component does not provide any intermediate events.

The receivefax completion reason MUST be one of the core Rayo reasons or finish (indicating that the document was fully received). Receivefax component completion provides a fax element only when a document was successfully received.

The server MUST present the fax for consumption by the client by way of fax metadata on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size & page count data as specified on the fax element. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.

]]>

Sending faxes can be achieved by using the Sendfax component. A conformant server MUST support image/tiff documents, and MAY also support others. A conformant server MUST support fetching documents via an HTTP URL and MAY support other URL schemes.

]]>

Additionally, a sendfax component MAY include in its completion reason one or more <metadata/> elements describing the result of transmitting the document, like so:

]]>

Instructs the server to begin receiving a fax.

The <receivefax/> element MUST be empty.

The <receivefax/> element has no attributes.

Instructs the server to begin transmitting a fax.

The <sendfax/> element MUST be empty.

The <sendfax/> element has no attributes.

Provides the result of a received fax, as a reference to its location.

The <fax/> element MUST be empty.

The attributes of the <fax/> element are as follows.

Attribute Definition Possible Values Inclusion
url Indicates the URL at which the fax is made available. A valid URI. REQUIRED
resolution Indicates the resolution of the received fax. A string in MxN format, where M and N are integers in pixels. REQUIRED
pages Indicates the number of pages in the received fax. An integer. REQUIRED
size Indicates the filesize of the received fax. A positive integer in bytes. REQUIRED

Provides data for a document to be sent as a fax.

The <document/> element MUST be empty.

The attributes of the <document/> element are as follows.

Attribute Definition Possible Values Inclusion
url Indicates the URL at which the document to send is available. A valid URI. REQUIRED
identity Indicates the identity from which the fax should appear to be sent. A phone number string in E.164 format. OPTIONAL
header The header line to add to each page of the transmitted fax. A string. OPTIONAL
pages The (set of) range of pages of the document to transmit. A string (or set of strings separated by ',') in the format M[-N], where M and N are integers and the dash and second integer are optional. The set is combinatory and dash-separated integers signify a range of pages. The index is one-based. OPTIONAL

Provides implementation-specific key-value pairs of metadata regarding the transmission or receipt of a fax document.

The <metadata/> element MUST be empty.

The attributes of the <metadata/> element are as follows.

Attribute Definition Inclusion
name A token giving the name by which the metadata may be known. REQUIRED
value The string value of the named metadata. REQUIRED

Indicates that the component came to an end due to the document being received successfully.

The <finish/> element MUST be empty.

The <finish/> element has no attributes.

If a Rayo server supports Rayo Fax, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo:fax:1" &VNOTE; in response to a &xep0030; information request.

]]> ]]>

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions.

This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

This document requires no interaction with &IANA;.

This specification defines the following XML namespaces:

  • urn:xmpp:rayo:fax:1
  • urn:xmpp:rayo:fax:complete:1

The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

 The protocol documented by this schema is defined at http://rayo.org/xep Instructs the server to begin receiving a fax. Instructs the server to begin transmitting a fax. Provides the result of a received fax, including a reference to its location. Indicates the URL at which the document to send is available. Indicates the identity from which the fax should appear to be sent. The header line to add to each page of the transmitted fax. A string (or set of strings separated by ',') in the format M[-N], where M and N are integers and the dash and second integer are optional. The set is combinatory and dash-separated integers signify a range of pages. The index is one-based. ]]> The protocol documented by this schema is defined at http://rayo.org/xep Provides the result of a received fax, including a reference to its location. Indicates the URL at which the fax is made available. Indicates the resolution of the received fax in MxN format, where M and N are integers in pixels. Indicates the number of pages in the received fax. Indicates the filesize (in bytes) of the received fax. A token giving the name by which the metadata may be known. The string value of the named metadata. Indicates that the component came to an end due to the document being received successfully. ]]>

The authors would like to acknowledge the input of teams at Mojo Lingo and Grasshopper in the development of this specification.

Specific individuals who have contributed to the specification or to software significant to its completion include: