moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

xhtml fixes

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@535 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-14 02:57:53 +00:00
parent 81f37952a3
commit a20276973b
10 changed files with 206 additions and 172 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
xep-0071.xml
View File

@ -169,12 +169,12 @@
<section1 topic='Choice of Technology' anchor='tech'>
<p>In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.</p>
<p>Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &XSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:</p>
<ol type='1' start='1'>
<ol>
<li>RTF is not a structured vocabulary derived from SGML (as is &w3html;) or, more relevantly, from XML (as is XHTML 1.0).</li>
<li>RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the XSF is unable to contribute to or influence its development if necessary, and any protocol the XSF developed using RTF would introduce unwanted dependencies.</li>
</ol>
<p>Conversely, there are several reasons to prefer XHTML for lightweight text markup:</p>
<ol type='1' start='1'>
<ol>
<li>XHTML is a structured format that is defined as an application of &w3xml;, making it especially appropriate for sending over Jabber/XMPP, which is at root a technology for streaming XML (see &xmppcore;).</li>
<li>XHTML is an open standard developed by the &W3C;, a recognized standards development organization.</li>
</ol>
@ -182,7 +182,7 @@
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>HTML was originally designed for authoring and presenting stuctured documents on the World Wide Web, and was subsequently extended to handle more advanced functionality such as image maps and interactive forms. However, the requirements for publishing documents (or developing transactional websites) for presentation by dedicated XHTML clients on traditional computers or small-screen devices are fundamentally different from the requirements for lightweight text markup of instant messages; for this reason, only a reduced set of XHTML features is needed for XHTML-IM. In particular:</p>
<ol type='1' start='1'>
<ol>
<li><p>IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read <em>and generate</em> relatively large numbers of fairly small instant messages.</p></li>
<li><p>The underlying context for XHTML content in Jabber/XMPP instant messaging is provided not by a full XHTML document, but by an XML stream, and specifically by a message stanza within that stream. Thus the &lt;head/&gt; element and all its children are unnecessary. Only the &lt;body/&gt; element and some of its children are appropriate for use in instant messaging.</p></li>
<li><p>The XHTML content that is read by one's IM client is normally generated on the fly by one's conversation partner (or, to be precise, by his or her IM client). Thus there is an inherent limit to the sophistication of the XHTML markup involved. Even in normal XHTML documents, fairly basic structural and rendering elements such as definition lists, abbreviations, addresses, and computer input handling (e.g., &lt;kbd/&gt; and &lt;var/&gt;) are relatively rare. There is little or no foreseeable need for such elements within the context of instant messaging.</p></li>
@ -208,7 +208,7 @@
</message>
]]></example>
<p>Technically speaking, there are three aspects to the approach taken herein:</p>
<ol type='1' start='1'>
<ol>
<li>Definition of the &lt;html/&gt; "wrapper" element, which functions as an XMPP extension within XMPP &lt;message/&gt; stanzas.</li>
<li>Definition of the XHTML-IM Integration Set itself in terms of supported XHTML 1.0 modules, using the concepts defined in &w3xhtmlmod;.</li>
<li>A recommended "profile" regarding the specific XHTML 1.0 elements and attributes to be supported from each XHTML 1.0 module.</li>
@ -334,7 +334,7 @@
<p>A full list of recommended style properties is provided below.</p>
<section3 topic='Recommended Style Properties' anchor='profile-style-properties'>
<p><cite>CSS1</cite> defines 42 "atomic" style properties (which are categorized into font, color and background, text, box, and classification properties) as well as 11 "shorthand" properties ("font", "background", "margin", "padding", "border-width", "border-top", "border-right", "border-bottom", "border-left", "border", and "list-style"). Many of these properties are not appropriate for use in text-based instant messaging, for one or more of the following reasons:</p>
<ol type='1' start='1'>
<ol>
<li>The property applies to or depends on the inclusion of images other than those handled by the XHTML Image Module (e.g., the "background-image", "background-repeat", "background-attachment", "background-position", and "list-style-image" properties).</li>
<li>The property is intended for advanced document layout (e.g., the "line-height" property and most of the box properties, with the exception of "margin-left", which is useful for indenting text, and "margin-right", which can be useful when dealing with images).</li>
<li>The property is unnecessary since it can be emulated via user input or recommended XHTML stuctural elements (e.g., the "text-transform" property can be emulated by the user's keystrokes or use of the caps lock key)</li>
@ -514,7 +514,7 @@
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
<p>The following rules apply to the generation and processing of XHTML content by Jabber clients or other XMPP entities.</p>
<ol type='1' start='1'>
<ol>
<li><p>XHTML-IM content is designed to provide a formatted version of the XML character data provided in the &BODY; of an XMPP &MESSAGE; stanza; if such content is included in an XMPP message, the &lt;html/&gt; element MUST be a direct child of the &MESSAGE; stanza and the XHTML-IM content MUST be understood as a formatted version of the message body. XHTML-IM content MAY be included within XMPP &IQ; stanzas (or children thereof), but any such usage is undefined. In order to preserve bandwidth, XHTML-IM content SHOULD NOT be included within XMPP &PRESENCE; stanzas; however, if it is so included, the &lt;html/&gt; element MUST be a direct child of the &PRESENCE; stanza and the XHTML-IM content MUST be understood as a formatted version of the XML character data provided in the &STATUS; element.</p></li>
<li><p>The sending client MUST ensure that, if XHTML content is sent, its meaning is the same as that of the plaintext version, and that the two versions differ only in markup rather than meaning.</p></li>
<li><p>XHTML-IM is a reduced set of <cite>XHTML 1.0</cite> and thus also of <cite>XML 1.0</cite>. Therefore all opening tags MUST be completed by inclusion of an appropriate closing tag.</p></li>
@ -625,7 +625,7 @@
<p>This could be rendered as follows:</p>
<div class='example'>
<p>Here&apos;s my .plan for today:</p>
<ol type='1' start='1'>
<ol>
<li>Add the following examples to XEP-0071:
<ul>
<li>ordered and unordered lists</li>
@ -783,11 +783,11 @@ That seems fine to me.
-//JSF//DTD Instant Messaging with XHTML//EN
]]></code>
<p>The fields of this FPI are as follows:</p>
<ol type='1' start='1'>
<ol>
<li>The leading field is "-", which indicates that this is a privately-defined resource.</li>
<li>The second field is "JSF" (an abbreviation for Jabber Software Foundation, the former name for the XMPP Standards Foundation), which identifies the organization that maintains the named item.</li>
<li>The third field contains two constructs:
<ol type='1' start='1'>
<ol>
<li>The public text class is "DTD", which adheres to ISO 8879 Clause 10.2.2.1.</li>
<li>The public text description is "Instant Messaging with XHTML", which contains but does not begin with the string "XHTML" (as recommended for an XHTML 1.0 Integration Set).</li>
</ol>

2
xep-0077.xml
View File

@ -143,7 +143,7 @@
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>In-band registration must make it possible for an entity to register with a host, cancel an existing registration with a host, or change a password with a host. By "host" is meant either of the following:</p>
<ol type='1' start='1'>
<ol>
<li>an instant messaging server, such as described in <cite>XMPP IM</cite> and identified by the "server/im" &xep0030; category+type</li>
<li>an add-on service, such as a gateway (see &xep0100;) or a &xep0045; service</li>
</ol>

6
xep-0079.xml
View File

@ -157,7 +157,7 @@
<section1 topic='Process Flows' anchor='process'>
<section2 topic='Sender-to-Server' anchor='process-s2s'>
<p>The following use case flow describes the interaction between the sender and a server. As illustrated below, this interaction is actually rather simple:</p>
<ol type='1' start='1'>
<ol>
<li>Sender determines support (E1)</li>
<li>Sender specifies appropriate rules and sends message to server (E1,E2)</li>
<li>Sender awaits any protocol-specific responses (UCE)</li>
@ -260,7 +260,7 @@
</section2>
<section2 topic='Server Processing' anchor='process-server'>
<p>Server operation is where the bulk of the work is performed. Upon receiving a message with an AMP extension, the server performs the following flow:</p>
<ol type='1' start='1'>
<ol>
<li>Validate the semantics (E1, E2).</li>
<li>Determine the default behavior.</li>
<li>Process rules until condition is met.
@ -328,7 +328,7 @@
<p>In the following sections, the terms "content" and "contents" refers to the XML character data contained by the &lt;rule/&gt; element.</p>
<section3 topic='deliver' anchor='conditions-def-deliver'>
<p>The "deliver" condition is used to ensure delivery (or non-delivery) in one of five ways:</p>
<ol type='1' start='1'>
<ol>
<li>Directly to the specified address or account over XMPP</li>
<li>Delayed to offline storage (for later delivery via XMPP)</li>
<li>Forwarded to an alternate address or account over XMPP</li>

286
xep-0129.xml
View File

@ -7,11 +7,11 @@
<xep>
<header>
<title>WebDAV File Transfers</title>
<abstract>This document specifies best practices for completing Jabber file transfers using WebDAV.</abstract>
<abstract>This document a method for completing Jabber file transfers using WebDAV.</abstract>
&LEGALNOTICE;
<number>0129</number>
<status>Deferred</status>
<type>Informational</type>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
@ -22,24 +22,30 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>webdav-filexfer</shortname>
<shortname>TO BE ASSIGNED</shortname>
&dizzyd;
&stpeter;
<revision>
<version>0.3</version>
<date>2007-02-02</date>
<initials>psa</initials>
<remark><p>Incorporated WedDAV feedback.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2004-04-13</date>
<initials>psa</initials>
<remark>Added information about service discovery.</remark>
<remark><p>Added information about service discovery.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2004-03-12</date>
<initials>psa</initials>
<remark>Initial version.</remark>
<initials>psa/ds</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518;.</p>
<p>&xep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518; (see also the revision-in-progress, &rfc2518bis;).</p>
<p>The use case in which the recipient is offline is the main driver behind this document. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -50,12 +56,123 @@
</ol>
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='HTTP Terms' anchor='terms-http'>
<p>This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.</p>
</section2>
<p>This document inherits terms from <cite>RFC 2518</cite>, &rfc2616;, and &rfc2617;.</p>
</section1>
<section1 topic='Protocol Flow' anchor='protocol'>
<p>The client SHOULD attempt to PUT the file on the server. <note>Alternatively, the client MAY first attempt one or more HEAD requests to determine a unique URL.</note> The PUT request MUST include an "If-None-Match" header as well as an "Authorization" header that specifies appropriate authentication information.</p>
<example caption='Initial PUT Request'><![CDATA[
PUT /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: Basic cm9tZW9AbW9udGFndWUubmV0
If-None-Match: *
Content-Length: xxx
Content-Type: text/html
[body omitted]
]]></example>
<p>Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to DELETE, MOVE, PROPPATCH, etc.</p>
<example caption='HTTP OK'><![CDATA[
HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 15:01:20 GMT
]]></example>
<p>In the absence of any other authorization method (e.g., SAML) in use by the deployed WebDAV server, the client MUST perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.</p>
<example caption='PROPPATCH Request'><![CDATA[
PROPPATCH /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: x-xmpp-auth jid=[base64 encoded jid]
Content-Type: text/xml
Content-Length: 176
<propertyupdate xmlns='DAV:'>
<set>
<prop>
<jidlist xmlns='http://www.xmpp.org/extensions/xep-0129.html#ns'>
<jid>juliet@capulet.com</jid>
<jid>benvolio@montague.net/home</jid>
<jid>mercutio@capulet.com</jid>
</jidlist>
</prop>
</set>
</propertyupdate>]]></example>
<p>Note: The semantics of the JID list defined above are:</p>
<ul>
<li>If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).</li>
<li>If a JID includes a resource identifier, only that specific JID may access this URL (in the example above, this means that only the JID benvolio@montague.net/home may access this URL; benvolio@montague.net/other may NOT).</li>
<li>If both a full JID and a bare JID are specified in a single JID list, the bare JID takes precedence.</li>
</ul>
<p>The server responds when the properties have been updated. This is typically a 207 (MultiPart) response, which means that the body can contain multiple status codes, as shown in the following example.</p>
<example caption='Server Returns HTTP 207'><![CDATA[
HTTP/1.1 207 MultiPart Response
Date: Thu, 18 Dec 2003 15:03:20 GMT
Content-Type: text/xml; charset=UTF-8
Content-Length: 211
<multistatus xmlns='DAV:'>
<response>
<href>http://files.shakespeare.lit/uniqueurl</href>
<propstat>
<prop><jidlist xmlns='http://www.xmpp.org/extensions/xep-0129#ns'/></prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
]]></example>
<p>Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p>
<example caption='Sender Generates XMPP Message with URL'><![CDATA[
<message from='romeo@montague.net/pda' to='multicast.jabber.org'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='juliet@capulet.com/chamber'/>
<address type='to' jid='benvolio@montague.net/home'/>
<address type='cc' jid='mercutio@capulet.com/pda'/>
</addresses>
<x xmlns='jabber:x:oob'>
<url>http://files.shakespeare.lit/uniqueurl</url>
</x>
</message>
]]></example>
<p>When the target recipients have received the message, they may then perform an HTTP GET to download the file (the following request is from juliet@capulet.com).</p>
<example caption='Recipient GET Request'><![CDATA[
GET /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: Basic anVsaWV0QGNhcHVsZXQuY29t
]]></example>
<p>The server then checks to ensure that the provided JID is on the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:</p>
<example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal'
from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>
Someone (maybe you) has requested the following file:
https://files.shakespeare.lit:9345/missive.html.
The transaction identifier is:
a7374jnjlalasdf82
If you wish to confirm the request, please reply
to this message by typing "OK". If not, please
reply with "No".
</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
id='a7374jnjlalasdf82'
method='GET'
url='https://files.shakespeare.lit:9345/missive.html'/>
</message>
]]></example>
<p>If the <cite>XEP-0070</cite> verification is successful, the server then allows the file to be retrieved:</p>
<example caption='Server Returns File'><![CDATA[
HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 18:00:00 GMT
Content-Type: text/html
Content-Length: xxx
[body omitted]
]]></example>
</section1>
<section1 topic='Discovery' anchor='disco'>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.</p>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" (see <link url='#ns'>Protocol Namespaces</link>). An example of the discovery flow is shown below.</p>
<example caption='Client Discovers Services'><![CDATA[
<iq from='romeo@shakespeare.lit/home'
id='disco1'
@ -90,131 +207,48 @@
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='http://jabber.org/protocol/http-auth'/>
<feature var='http://jabber.org/protocol/webdav-filexfer'/>
<feature var='http://www.xmpp.org/extensions/xep-0129.html#ns'/>
...
</query>
</iq>
]]></example>
<p>The user now knows that the "files.shakespeare.lit" service supports this protocol.</p>
</section1>
<section1 topic='Protocol Flow' anchor='protocol'>
<p>The client MUST generate a unique URL and execute an HTTP HEAD request to see if that URL exists; this action SHOULD be repeated until the WebDAV server returns a 404 Not Found.</p>
<code><![CDATA[
HEAD /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
]]></code>
<p>Because the WebDAV server supports &xep0070;, the initial request fails (since the user did not provide Jabber authentication).</p>
<code><![CDATA[
HTTP/1.1 401 Unauthorized
WWW-Authenticate: x-xmpp-auth realm=xmpp
]]></code>
<p>In this case, the client then re-requests the HEAD with the appropriate credentials. Of course, the client could have avoided this by just providing the Authorization header on the initial request.</p>
<code><![CDATA[
HEAD /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: x-xmpp-auth jid=[base64 encoded jid]
]]></code>
<p>Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in XEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.</p>
<p>In the "happy" path, the server responds that the requested URL was not found.</p>
<code><![CDATA[
HTTP/1.1 404 Not Found
Date: Thu, 18 Dec 2003 15:00:00 GMT
]]></code>
<p>Now the client can PUT the file on the server, with the unique URL. To protect against someone else using the same URL in the timeframe between the HEAD and the PUT, the client MUST include an If-None-Match:* header to ensure that the server will not allow another URL to be overwritten.</p>
<code><![CDATA[
PUT /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: xmpp-auth (base64 encoded jid)
If-None-Match: *
Content-Length: xxx
Content-Type: text/html
[body omitted]
]]></code>
<p>Prior to storing the file, the server MUST verifies the user's authorization (as detailed above). When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to DELETE, MOVE, PROPPATCH, etc.</p>
<code><![CDATA[
HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 15:01:20 GMT
]]></code>
<p>In the absence of any other authorization method (e.g., SAML) in use by the deployed WebDAV server, the client MUST perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.</p>
<code><![CDATA[
PROPPATCH /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: x-xmpp-auth jid=[base64 encoded jid]
Content-Type: text/xml
Content-Length: 176
<propertyupdate xmlns='DAV:'>
<set>
<prop>
<jidlist xmlns='jabberjidlisturl'>
<jid>juliet@capulet.com</jid>
<jid>benvolio@montague.net/home</jid>
<jid>mercutio@capulet.com</jid>
</jidlist>
</prop>
</set>
</propertyupdate>]]></code>
<p>Note: The semantics of the JID list defined above are:</p>
<ul>
<li>If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).</li>
<li>If a JID includes a resource identifier, only that specific JID may access this URL (in the example above, this means that only the JID benvolio@montague.net/home may access this URL; benvolio@montague.net/other may NOT).</li>
<li>If both a full JID and a bare JID are specified in a single JID list, the bare JID takes precedence.</li>
</ul>
<p>The server responds when the properties have been updated. The book "WebDAV: Next-Generation Collaborative Web Authoring" (Prentice Hall, 2004) suggests that this is typically a 207 (MultiPart) response, which means that the body can contain multiple status codes, as shown in the following example.</p>
<code><![CDATA[
HTTP/1.1 207 MultiPart Response
Date: Thu, 18 Dec 2003 15:03:20 GMT
Content-Type: text/xml; charset=UTF-8
Content-Length: 211
<multistatus xmlns='DAV:'>
<response>
<href>http://files.shakespeare.lit/uniqueurl</href>
<propstat>
<prop><jidlist xmlns='jabberjidlisturi'/></prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
]]></code>
<p>Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p>
<code><![CDATA[
<message to='multicast.jabber.org'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='juliet@capulet.com/chamber'/>
<address type='to' jid='benvolio@montague.net/home'/>
<address type='cc' jid='mercutio@capulet.com/pda'/>
</addresses>
<x xmlns='jabber:x:oob'>
<url>http://files.shakespeare.lit/uniqueurl</url>
</x>
</message>
]]></code>
<p>When the target recipients have received the message, they may then perform an HTTP GET to download the file.</p>
<code><![CDATA[
GET /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
Authorization: xmpp-auth (base64 encoded JID; juliet@capulet.com)
]]></code>
<p>The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via XEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.</p>
<code><![CDATA[
HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 18:00:00 GMT
Content-Type: text/html
Content-Length: xxx
[body omitted]
]]></code>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See <strong>RFC 2518</strong>, <strong>XMPP Core</strong>, and <strong>XEP-0070</strong> for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.</p>
<p>See <cite>RFC 2518</cite>, <cite>XMPP Core</cite>, and <cite>XEP-0070</cite> for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>Upon advancement of this document to a status of Active, the &REGISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.</p>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0129.html#ns"; upon advancement of this specification, the &REGISTRAR; shall issue one or more permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.xmpp.org/extensions/xep-0186.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0186.html#ns'
elementFormDefault='qualified'>
<xs:element name='invisible' type='empty'/>
<xs:element name='visible' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Lisa Dusseault and Julian Reschke for their feedback.</p>
</section1>
</xep>

46
xep-0130.xml
View File

@ -220,14 +220,14 @@
</section1>
<section1 topic="Requirements" anchor='reqs'>
<p>This protocol is designed so that an IM User can:</p>
<ol type='1' start='1'>
<ol>
<li>Request the user's current Waiting List</li>
<li>Add a Contact to a local WaitingList (based on some URI associated with the Contact)</li>
<li>Receive notification from a local WaitingListService if the Contact has (or subsequently creates) an IM account</li>
<li>Remove a Contact from the Waiting List</li>
</ol>
<p>In addition, this protocol is designed so that a ServiceProvider can:</p>
<ol type='1' start='1'>
<ol>
<li>Request the service's current WaitingList</li>
<li>Add a Contact to a WaitingList at an InteroPartner (based on some URI associated with the Contact)</li>
<li>Receive notification from the InteropPartner if the Contact has (or subsequently creates) an IM account</li>
@ -238,21 +238,21 @@
<section2 topic="IM User Retrieves Current WaitingList" anchor='imuser-retrieve'>
<p>Before adding or removing Contacts from its WaitingList, an IM User SHOULD retrieve its current WaitingList. The activity flow is as follows:</p>
<section3 topic="Primary Flow" anchor='imuser-retrieve-primary'>
<ol type='1' start='1'>
<ol>
<li>IM User discovers WaitingListService hosted by ServiceProvider [A1]; it is RECOMMENDED to do this immediately after logging in.</li>
<li>IM User requests current WaitingList from WaitingListService.</li>
<li>WaitingListService returns WaitingList to IM User, including any items for which JIDs have been discovered. [A2]</li>
</ol>
</section3>
<section3 topic="Alternate Flows" anchor='imuser-retrieve-alt'>
<ol type='1' start='1'>
<ol>
<li>ServiceProvider does not host a WaitingListService:
<ol type='1' start='1'>
<ol>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>IM User does not have a Waiting List:
<ol type='1' start='1'>
<ol>
<li>WaitingListService returns &notfound; error to IM User.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
@ -263,7 +263,7 @@
<section2 topic="IM User Adds Contact to WaitingList" anchor='imuser-add'>
<p>An IM User may know a URI for a Contact (e.g., a phone number or email address) but not the Contact's JID. In order to subscribe to the Contact's presence or otherwise communicate with the Contact over an instant messaging system, the IM User first needs to discover the Contact's JID based on a URI for the Contact. However, the Contact may not yet have an IM account. Because the IM User may therefore need to wait until the Contact creates an account, the IM User needs to add the Contact to a WaitingList. The activity flow is as follows:</p>
<section3 topic="Primary Flow" anchor='imuser-add-primary'>
<ol type='1' start='1'>
<ol>
<li>IM User completes <link url='#imuser-retrieve'>IM User Retrieves Current WaitingList</link> use case.</li>
<li>IM User requests addition of Contact to WaitingList based on Contact's URI.</li>
<li>WaitingListService determines that the URI scheme is supported. [A1]</li>
@ -281,21 +281,21 @@
</ol>
</section3>
<section3 topic="Alternate Flows" anchor='imuser-add-alt'>
<ol type='1' start='1'>
<ol>
<li>The URI scheme is not supported:
<ol type='1' start='1'>
<ol>
<li>WaitingListService sends &badrequest; error to IM User and does not add contact to WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>The information provided is not a valid URI:
<ol type='1' start='1'>
<ol>
<li>WaitingListService sends &notacceptable; error to IM User and does not add contact to WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>URI belongs to person served by ServiceProvider:
<ol type='1' start='1'>
<ol>
<li>WaitingListService determines that Contact is an IM User registered with ServiceProvider [A7].</li>
<li>WaitingListService informs IM User of Contact's JID. [A9]</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
@ -303,7 +303,7 @@
</ol>
</li>
<li>URI does not belong to a person served by InteropPartner:
<ol type='1' start='1'>
<ol>
<li>InteropPartner sends &notfound; error to WaitingListService.</li>
<li>If all InteropPartners queried return &notfound; error, WaitingListService sends &notfound; error (or local equivalent) to IM User.</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
@ -311,7 +311,7 @@
</ol>
</li>
<li>Contact is not an IM User registered with InteropPartner:
<ol type='1' start='1'>
<ol>
<li>InteropPartner records and acknowledges WaitingListService's request for JID associated with URI.</li>
<li>OPTIONALLY, InteropPartner invites Contact to register as an IM User.</li>
<li>Contact registers.</li>
@ -322,14 +322,14 @@
</ol>
</li>
<li>InteropPartner refuses to provide service to ServiceProvider:
<ol type='1' start='1'>
<ol>
<li>InteropPartner's WaitingListService sends &notauthorized; error to ServiceProvider's WaitingListService.</li>
<li>If all other InteropPartners also return errors, WaitingListService returns &notfound; error to IM User.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>Contact is not an IM User registered with ServiceProvider:
<ol type='1' start='1'>
<ol>
<li>WaitingListService records IM User's request for JID associated with URI.</li>
<li>OPTIONALLY, WaitingListService invites Contact to register as an IM User.</li>
<li>Contact registers.</li>
@ -339,20 +339,20 @@
</ol>
</li>
<li>Contact's URI is not handled by any ServiceProvider:
<ol type='1' start='1'>
<ol>
<li>WaitingListService informs all IM Users who requested JID associated with Contact's URI that no InteropPartner services Contact's URI.</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.
<ol type='1' start='1'>
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>All Users Remove Contact from Their WaitingLists
<ol type='1' start='1'>
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
@ -363,7 +363,7 @@
<section2 topic="IM User Removes Contact from WaitingList" anchor='imuser-remove'>
<p>An IM User should remove a contact from the WaitingList after the <link url='#imuser-add'>IM User Adds Contact to WaitingList</link> use case ends (either successfully or unsuccessfully), and may remove a contact from the WaitingList at any other time.</p>
<section3 topic="Primary Flow" anchor='imuser-remove-primary'>
<ol type='1' start='1'>
<ol>
<li>IM User sends removal request to WaitingListService.</li>
<li>WaitingListService removes IM User's request for JID associated with URI.</li>
<li>WaitingListService informs IM User of successful removal [A1].</li>
@ -375,15 +375,15 @@
</ol>
</section3>
<section3 topic="Alternate Flows" anchor='imuser-remove-alt'>
<ol type='1' start='1'>
<ol>
<li>IM User never requested JID associated with URI:
<ol type='1' start='1'>
<ol>
<li>WaitingListService sends &notfound; error to IM User.</li>
<li>Use Case Ends.</li>
</ol>
</li>
<li>Contact URI is served by WaitingListService or IM User was not the only person who requested the JID:
<ol type='1' start='1'>
<ol>
<li>Use Case Ends.</li>
</ol>
</li>
@ -900,7 +900,7 @@
</section2>
</section1>
<section1 topic="Implementation Notes" anchor='impl'>
<ol type='1' start='1'>
<ol>
<li><p>Protocols and mechanisms for inviting a Contact to register as an IM User are out of scope for this document and shall be determined by each InteropPartner individually.</p></li>
<li><p>A ServiceProvider's WaitingListService MUST record which of its IM Users have requested the JID associated with Contact's URI, and an InteropPartner's WaitingListService MUST record that Service Provider's WaitingListService (not User) has requested JID associated with Contact's URI. Therefore when Contact registers, InteropPartner's WaitingListService informs its local users as well as ServiceProvider's WaitingListService, and ServiceProvider's WaitingListService informs its local users.</p></li>
<li><p>The InteropPartner's WaitingListService is not required to be hosted by InteropPartner, and could be hosted by a third party (e.g., a neutral phone number translation service). In this case, InteropPartner would simply advertise 'waitlist.third-party.com' as its WaitingListService.</p></li>

6
xep-0139.xml
View File

@ -57,10 +57,10 @@
</section1>
<section1 topic='Deliverables' anchor='deliverables'>
<p>The Security SIG shall produce at least the following deliverables:</p>
<ol type='1' start='1'>
<ol>
<li>
<p>A brief document specifying the process by which the SIG shall identify, define, analyze, and prioritize a collection of documented security-related threats. This process document will not identify threats or define ways to address them, but instead specify the process to be followed in Steps 2 and 3 below. In defining the process, the SIG should also describe some of its guiding principles, such as:</p>
<ol type='1' start='1'>
<ol>
<li>Rough consensus and running code are superior to "perfect" solutions</li>
<li>Security measures that cannot or will not be implemented are useless</li>
<li>Iteration works better than trying to define all solutions up front</li>
@ -68,7 +68,7 @@
</li>
<li>
<p>A template to be used for documenting each identified threat. This template should include:</p>
<ol type='1' start='1'>
<ol>
<li>A name for the threat</li>
<li>An abstract that briefly describes the threat</li>
<li>A clear and thorough definition of the threat, preferably to include an attack tree <note>For information about attack trees, refer to &lt;<link url="http://www.schneier.com/paper-attacktrees-ddj-ft.html">http://www.schneier.com/paper-attacktrees-ddj-ft.html</link>&gt;.</note></li>

2
xep-0162.xml
View File

@ -131,7 +131,7 @@
<li>
<p>The Jabber client SHOULD NOT remove the contact from the roster. There
are two exceptions:</p>
<ol type='a'>
<ol style='list-style-type: lower-alpha'>
<li><p>The Jabber client MAY remove the contact from the roster if the user
explicitely asked (so the user has to be informed he might remove both
presence subscriptions).</p></li>

2
xep-0163.xml
View File

@ -476,7 +476,7 @@
</pubsub>
</iq>
]]></example>
<p>As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the <link url='#notifications'>Contact Notification Filtering</link> and <link url='#notifications'>Generating Notifications</link> sections of this document.</p>
<p>As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the <link url='#notifications'>Contact Notification Filtering</link> and <link url='#notifications'>Generating Notifications</link> sections of this document, as well as to any of the account owner's available resources.</p>
<p>The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &xep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.</p>
<p>Assuming that all three entities previously mentioned would receive the notifications, the PEP service would generate the following stanzas:</p>
<example caption='Server sends notification to subscribers'><![CDATA[

4
xep-0171.xml
View File

@ -101,7 +101,7 @@
<li><p>Enable an XMPP entity to request a translation from a remote XMPP entity.</p></li>
<li>
<p>Enable an XMPP entity to express the following mandatory elements of a translation for any receiving entities.</p>
<ol type='a'>
<ol style='list-style-type: lower-alpha'>
<li>Identification of Original Text</li>
<li>Identification of Translated Text</li>
<li>Identification of any Pivot Language(s) and Text</li>
@ -110,7 +110,7 @@
</li>
<li>
<p>Enable an XMPP entity to express the following optional elements of a translation for any receiving entities.</p>
<ol type='a'>
<ol style='list-style-type: lower-alpha'>
<li>Identification of Language Translation Engines used.</li>
<li>Identification of Location of the translation.</li>
<li>Identification of Sender and Destination language of choice.</li>

6
xep-0204.xml
View File

@ -102,7 +102,7 @@
<!-- REQUIREMENTS -->
<section1 topic="Requirements" anchor="reqs">
<p>This JEP describes a protocol that is designed to fulfill the following requirements: </p>
<ol type="one">
<ol>
<li>Determine the ability for clients and servers to support and exchange collaborative data objects</li>
<li>Enable the exchange of structured data objects between clients</li>
<li>Define a protocol that supports the synchronization of structure data among participating clients. Currently
@ -133,7 +133,7 @@
Both clients want to ensure they have the most up-to-date information. The two endpoints can do so by collaborating on the data using the CDO protocol.
</p>
<p>For example, let's assume the clients wish to coordinate a meeting over chat. The process may look like this:</p>
<ol type="one">
<ol>
<li>Client
<strong>A</strong> creates a new meeting that contains structured data such as the title of the meeting, participant e-mail list, start time, date,
length, and location.
@ -158,7 +158,7 @@
<strong>A</strong> and
<strong>B</strong> are connected to.
</p>
<ol type="one">
<ol>
<li>Client
<strong>A</strong> wishes to send information about a new meeting to client
<strong>B</strong>