mirror of https://github.com/moparisthebest/xeps
fixed dead links /psa
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3420 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Unknown User
parent
132eac876f
commit
6e921e3d88
|
|
@ -58,7 +58,7 @@
|
|||
<section1 topic='Specification'>
|
||||
<section2 topic='Interface'>
|
||||
<p>Interface is the process, steps, and protocol a Service has to go through to access the information with the User's approval, for the User to approve or reject the access, and the User's Server to manage and secure it all.</p>
|
||||
<p>Although it will be part of the Jabber protocol, it is still undecided how heavily the Profiles specification will rely on and use the Jabber system. This is the first thing that will have to be decided on, but thankfully there are some plans we have already outlined as possibilities, listed at the <link url="http://www.theoretic.com/identity">Theoretic Identity</link> website.</p>
|
||||
<p>Although it will be part of the Jabber protocol, it is still undecided how heavily the Profiles specification will rely on and use the Jabber system. This is the first thing that will have to be decided on, but thankfully there are some plans we have already outlined as possibilities.</p>
|
||||
</section2>
|
||||
<section2 topic='Structure'>
|
||||
<p>Structure is the format that the information will be stored in and accessed by. It will have to be very flexible, likely eventually allowing the User to specify the info-sets they want to use instead of having them all set by this project.</p>
|
||||
|
|
@ -91,6 +91,6 @@
|
|||
<p>It is important to note that this SIG will not be a stand-alone SIG. It will draw upon many other SIGs (that currently exist and that have yet to be created). It will need encryption from the Security SIG for safe transfer of the information, a versatile forms format from the Forms SIG for Profiles administration, and advanced authentication from a future SIG for Services to authenticate the User against their Jabber account.</p>
|
||||
</section1>
|
||||
<section1 topic='History'>
|
||||
<p>The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (<link url="http://www.theoretic.com/identity/">http://www.theoretic.com/identity/</link>), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official SIG that we have split the individual parts up, to make it easier to develop.</p>
|
||||
<p>The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions, although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official SIG that we have split the individual parts up, to make it easier to develop.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@
|
|||
<p>There are two methods for retrieving the actual avatar data:</p>
|
||||
<ol>
|
||||
<li>An exchange between clients of <iq/> elements in the jabber:iq:avatar namespace</li>
|
||||
<li>Public XML storage from the avatar-generating client to the server and public XML retrieval from the server to the avatar-requesting client <note>Refer to the <link url="http://docs.jabber.org/draft-proto/html/xml.html">Generic XML Namespace Storage</link> draft protocol.</note></li>
|
||||
<li>Public XML storage from the avatar-generating client to the server and public XML retrieval from the server to the avatar-requesting client (see &xep0049;).</li>
|
||||
</ol>
|
||||
<p>The first of these methods is preferred. On this model, a query is sent directly to the avatar-generating client using an <iq/> element of type "get" in the jabber:iq:avatar namespace <note>Whenever possible, the avatar-requesting client should attempt to determine if the avatar-generating client has an avatar available before requesting it.</note> <note>It is suggested that no request be made if it is known (such as through a browse reply) that a client does not support the jabber:iq:avatar namespace.</note>:</p>
|
||||
<example>
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@
|
|||
<section1 topic='Introduction'>
|
||||
<p>&xmlrpc; is a method of encoding RPC requests and responses in XML. The original specification defines HTTP (see &rfc2068;) as the only valid transport for XML-RPC payloads.</p>
|
||||
<p>Various initiatives exist already to transport XML-RPC payloads over Jabber. These initiatives were independent of each other and used slightly differing methods (e.g. carrying the payload in a <message/> element as opposed to an &IQ; stanza), resulting in potential interoperability problems.</p>
|
||||
<p>A working session during JabberCon 2001 resulted in a <link url="http://www.pipetree.com/jabber/jrpc.html">formalisation</link> of a single method. This document describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.</p>
|
||||
<p>A working session during JabberCon 2001 resulted in formalisation of a single method. This document describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.</p>
|
||||
</section1>
|
||||
<section1 topic='Jabber-RPC'>
|
||||
<p>The &IQ; stanza is used to transport XML-RPC payloads. XML-RPC requests are transported using an &IQ; stanza of type "set", and XML-RPC responses are transported using an &IQ; stanza of type "result". An &IQ; stanza MUST NOT contain more than one request or response.</p>
|
||||
|
|
|
|||
|
|
@ -34,8 +34,8 @@
|
|||
</header>
|
||||
<section1 topic='Introduction'>
|
||||
<p>Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.</p>
|
||||
<p>There exists today a protocol draft for sending streaming XPM over Jabber <note>XPM over Jabber (<link url="http://docs.jabber.org/draft-proto/html/sxpm.html">http://docs.jabber.org/draft-proto/html/sxpm.html</link>)</note>. XPM is a bitmap format, which makes it well-suited for certain applications (e.g., smaller drawings and sketches). However, significant changes in an XPM image will require sending large amounts of XML data (even with the compression described in the protocol draft). Also, for example, XPM does not scale without loss of resolution, nor does it support metadata. In addition, the current draft specifies the data format only, not the way the data will be sent or handled by Jabber servers and clients.</p>
|
||||
<p>Therefore, the Whiteboard SIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing SIG <note>Conferencing protocol draft (<link url="http://jabber.org/?oid=1538">http://jabber.org/?oid=1538</link>)</note>.</p>
|
||||
<p>There exists today a protocol draft for sending streaming XPM over Jabber. XPM is a bitmap format, which makes it well-suited for certain applications (e.g., smaller drawings and sketches). However, significant changes in an XPM image will require sending large amounts of XML data (even with the compression described in the protocol draft). Also, for example, XPM does not scale without loss of resolution, nor does it support metadata. In addition, the current draft specifies the data format only, not the way the data will be sent or handled by Jabber servers and clients.</p>
|
||||
<p>Therefore, the Whiteboard SIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing SIG.</p>
|
||||
</section1>
|
||||
<section1 topic='Deliverables'>
|
||||
<p>The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):</p>
|
||||
|
|
@ -43,7 +43,7 @@
|
|||
<p>A set of requirements that the proposed protocol should fulfill.</p>
|
||||
</section2>
|
||||
<section2 topic='Analysis of existing work'>
|
||||
<p>There are today at least four different attempts <note>Distributed SVG documents (<link url="http://www.jabber.org/?oid=1025">http://www.jabber.org/?oid=1025</link>)</note> <note>SVG over Jabber (<link url="http://www.protocol7.com/jabber/whiteboard_proposal.txt">http://www.protocol7.com/jabber/whiteboard_proposal.txt</link>)</note> <note>Jabberzilla Whiteboard (<link url="http://jabberzilla.mozdev.org/">http://jabberzilla.mozdev.org/</link>)</note> to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.</p>
|
||||
<p>There are today at least four different attempts <note>"Distributed SVG documents" (formerly at http://www.jabber.org/?oid=1025)</note> <note>SVG over Jabber (<link url="http://www.protocol7.com/jabber/whiteboard_proposal.txt">http://www.protocol7.com/jabber/whiteboard_proposal.txt</link>)</note> <note>Jabberzilla Whiteboard (<link url="http://jabberzilla.mozdev.org/">http://jabberzilla.mozdev.org/</link>)</note> to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.</p>
|
||||
</section2>
|
||||
<section2 topic='Graphics data format'>
|
||||
<p>One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.</p>
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
</revision>
|
||||
</header>
|
||||
<section1 topic="Introduction">
|
||||
<p>The XMPP Standards Foundation is a continuing experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Special Interest Groups (SIGs). <note>The proposal contained in this document formalizes some conclusions reached during a weekly discussion forum held by the XMPP Standards Foundation on 2002-01-23. A log of that discussion is available at <link url="http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html">http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html</link>. Further discussion within the Standards SIG has been helpful in clarifying the argument presented here.</note></p>
|
||||
<p>The XMPP Standards Foundation is a continuing experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Special Interest Groups (SIGs). <note>The proposal contained in this document formalizes some conclusions reached during a weekly discussion forum held by the XMPP Standards Foundation on 2002-01-23. A log of that discussion was formerly available at http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html. Further discussion within the Standards SIG has been helpful in clarifying the argument presented here.</note></p>
|
||||
</section1>
|
||||
<section1 topic="The Problem">
|
||||
<p>&xep0002; defined a SIG as "a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a SIG is to "produce acceptable enhancements to XMPP within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a SIG after a defined period of inactivity on the SIG's mailing list (normally six months).</p>
|
||||
|
|
@ -71,6 +71,6 @@
|
|||
<li>Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.</li>
|
||||
<li>If the Standards SIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards SIG. <note>One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, <link url="http://www.jabberstudio.org/">http://www.jabberstudio.org/</link>). Unlike the current SIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the XMPP Council.</note></li>
|
||||
</ol>
|
||||
<p>There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. <note>Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at <link url="http://www.jabber.org/bylaws.html">http://www.jabber.org/bylaws.html</link>.)</note></p>
|
||||
<p>There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. <note>Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at <link url="http://xmpp.org/xsf/docs/bylaws.shtml">http://www.jabber.org/bylaws.html</link>.)</note></p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@
|
|||
|
||||
<p>The protocol operates in the 'http://xml.cataclysm.cx/jabber/ens/' namespace.</p>
|
||||
|
||||
<p>A reference implementation is available at <link url='http://cataclysm.cx/jabber/ens.html'>http://cataclysm.cx/jabber/ens.html</link>.</p>
|
||||
<p>A reference implementation was formerly available at http://cataclysm.cx/jabber/ens.html.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Definitions'>
|
||||
|
|
|
|||
|
|
@ -46,7 +46,6 @@
|
|||
<p>
|
||||
Pubsub ("publish/subscribe") is a technique for coordinating the efficient
|
||||
delivery of information from publisher to consumer. This specification
|
||||
<note>An earlier draft of this specification can be found at <link url='http://www.pipetree.com/testwiki/JabberPubsubSpec'>http://www.pipetree.com/testwiki/JabberPubsubSpec</link>.</note>
|
||||
describes the use of pubsub within a Jabber context and is a result of
|
||||
two separate but related goals:
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@
|
|||
|
||||
<section1 topic='Introduction'>
|
||||
<p>This proposal standardizes the use of graphical emoticons and "genicons" in Jabber IM clients to prevent confusion and competing conventions that will soon arise, enabling client developers to spend their energy on more important parts of their projects.</p>
|
||||
<p><link url="http://www.wikipedia.com/wiki/Emoticon">Emoticons</link> are the text string 'smiley' or 'frowny' faces such as <tt>:-)</tt> and <tt>:-(</tt> that people often use in email or instant messaging to represent emotions. Genicons are a term being coined here to mean non-emotive text pictures (often called '<link url="http://www.wikipedia.com/wiki/Ascii+Art">ASCII Art</link>') that serve to replace typing the full word or to simply be cute or creative in the conversation.</p>
|
||||
<p><link url="http://www.wikipedia.com/wiki/Emoticon">Emoticons</link> are the text string 'smiley' or 'frowny' faces such as <tt>:-)</tt> and <tt>:-(</tt> that people often use in email or instant messaging to represent emotions. Genicons are a term being coined here to mean non-emotive text pictures (often called '<link url="http://en.wikipedia.org/wiki/ASCII_art">ASCII Art</link>') that serve to replace typing the full word or to simply be cute or creative in the conversation.</p>
|
||||
<p>Many new Internet users demand graphical emoticon and genicon support in their IM clients. We should satisfy their needs if we ever wish to see them use Jabber instead of another IM system.</p>
|
||||
<p>While traditionally emoticons and genicons have been typed and displayed as text, the recent trend of using graphics, and sometimes sounds, instead of text to represent these pictures will be assumed for purposes of this proposal. Also, the term "icon" will be used in place of "emoticon" and "genicon" for purposes of convenience.</p>
|
||||
</section1>
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
<version>0.2</version>
|
||||
<date>2003-10-20</date>
|
||||
<initials>psa</initials>
|
||||
<remark>At the request of the author, changed status to Retracted; interested parties should refer to <<link url="http://www.openaether.org/projects/jabber_database.html">http://www.openaether.org/projects/jabber_database.html</link>> for further information.</remark>
|
||||
<remark>At the request of the author, changed status to Retracted.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@
|
|||
|
||||
<section1 topic="How to store">
|
||||
<section2 topic="General information">
|
||||
<p> JID, category and type are stored as attributes of <tt><item/></tt> tag. Categories and types are the same as in disco. Official categories and types associated with disco are administered by the Jabber Assigned Names Authority (JANA); for details, see <link url='http://www.jabber.org/jana/disco.php'>http://www.jabber.org/jana/disco.php</link>.</p>
|
||||
<p> JID, category and type are stored as attributes of <tt><item/></tt> tag. Categories and types are the same as in disco. Official categories and types associated with disco are administered by the ®ISTRAR; see &DISCOCATEGORIES;.</p>
|
||||
<example><![CDATA[<item jid="jdev@conference.jabber.org"
|
||||
category="conference"
|
||||
type="text">]]></example>
|
||||
|
|
|
|||
|
|
@ -832,7 +832,7 @@ That seems fine to me.
|
|||
<p>In addition, an implementation MUST make it possible for a user to prevent the automatic fetching and presentation of images (rather than leave it up to the implementation).</p>
|
||||
</section2>
|
||||
<section2 topic='Phishing' anchor='security-phishing'>
|
||||
<p>To reduce the risk of phishing attacks <note>Phishing has been defined as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them" (see <link url='http://fstc.org/projects/counter-phishing-phase-1/'>Financial Services Technology Consortium Counter-Phishing Initiative: Phase I</link>).</note>, an implementation MAY choose to:</p>
|
||||
<p>To reduce the risk of phishing attacks <note>Phishing has been defined by the Financial Services Technology Consortium Counter-Phishing Initiative as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them".</note>, an implementation MAY choose to:</p>
|
||||
<ul>
|
||||
<li>Display the value of the XHTML 'href' attribute instead of the XML character data of the <a/> element.</li>
|
||||
<li>Display the value of XHTML 'href' attribute in addition to the XML character data of the <a/> element if the two values do not match.</li>
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@
|
|||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>&w3soap; is a lightweight protocol that defines a method for the exchange of messages independently from the programming language and platform. For interoperability, the SOAP specification is also agnostic about possible transport protocols, though almost all existing implementations use mainly HTTP.</p>
|
||||
<p>The primary limitation of HTTP consists in the fact that HTTP-based message exchanges allow only synchronous request-response semantics. To overcome this limitation, SMTP is often used to carry asynchronous messages, but it is a complex protocol and inefficient for passing short and frequent messages that should be delivered in close to real time.</p>
|
||||
<p>Thus XMPP (see &rfc3920;) can be the ideal transport protocol for many of the application fields of web services, since it can carry efficiently and reliably both types of messages, synchronous and asynchronous. Moreover, XMPP-based web services will not need complex support protocols, such as <cite>WS-Routing</cite> <note>WS-Routing Specification <<link url="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp">http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp</link>>.</note> and <cite>WS-Referral</cite> <note>WS-Referral Specification <<link url="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp">http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp</link>>.</note>, in order to deliver messages to entities that cannot be identified by static public IP addresses. Therefore, this document defines a binding of SOAP to XMPP as an alternative to the existing HTTP and SMTP bindings.</p>
|
||||
<p>Thus XMPP (see &rfc3920;) can be the ideal transport protocol for many of the application fields of web services, since it can carry efficiently and reliably both types of messages, synchronous and asynchronous. Moreover, XMPP-based web services will not need complex support protocols, such as <cite>WS-Routing</cite> and <cite>WS-Referral</cite>, in order to deliver messages to entities that cannot be identified by static public IP addresses. Therefore, this document defines a binding of SOAP to XMPP as an alternative to the existing HTTP and SMTP bindings.</p>
|
||||
<p>(Note: The main body of this document provides descriptive text suitable for use by XMPP developers. A formal description of the SOAP XMPP Binding itself is provided in the section of this document entitled <link url='#binding'>SOAP XMPP Binding</link>.)</p>
|
||||
</section1>
|
||||
|
||||
|
|
@ -1087,8 +1087,7 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic="Security Considerations" anchor='security'>
|
||||
<p>SOAP has been supplemented by several support protocols that help ensure message integrity and confidentiality (<cite>WS-Security</cite> <note>WS-Security <<link url="http://msdn.microsoft.com/ws/2002/04/Security/">http://msdn.microsoft.com/ws/2002/04/Security/</link>>.</note>) as well as transaction management for failing message exchanges (<cite>WS-Transaction</cite>
|
||||
<note>WS-Transaction <<link url="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transaction.asp">http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transaction.asp</link>>.</note>). These protocols are all based on SOAP messages and take into account that the underlying protocols can be unreliable and not trusted, thus there are no arguments against their application with XMPP. Alternatively, implementations MAY use native XMPP security such as &xmppe2e;.</p>
|
||||
<p>SOAP has been supplemented by several support protocols that help ensure message integrity and confidentiality (<cite>WS-Security</cite> <note>WS-Security <<link url="http://msdn.microsoft.com/ws/2002/04/Security/">http://msdn.microsoft.com/ws/2002/04/Security/</link>>.</note>) as well as transaction management for failing message exchanges (see <cite>WS-Transaction</cite>). These protocols are all based on SOAP messages and take into account that the underlying protocols can be unreliable and not trusted, thus there are no arguments against their application with XMPP. Alternatively, implementations MAY use native XMPP security such as &xmppe2e;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic="IANA Considerations" anchor='iana'>
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
<version>0.2</version>
|
||||
<date>2003-10-20</date>
|
||||
<initials>psa</initials>
|
||||
<remark>At the request of the author, changed status to Retracted; interested parties should refer to <<link url="http://www.openaether.org/projects/sac.html">http://www.openaether.org/projects/sac.html</link>> for further information.</remark>
|
||||
<remark>At the request of the author, changed status to Retracted.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
|
|
|
|||
|
|
@ -1091,9 +1091,7 @@
|
|||
<p>Method calls in JOAP are simply XML-RPC calls, as defined in
|
||||
XEP-0009.<note>XEP-0009 leaves some open questions as to use
|
||||
of widely-defined extensions to the XML-RPC standard, such as
|
||||
the <nil> type (see
|
||||
<link url='http://ontosys.com/xml-rpc/extensions.html'><nil>
|
||||
data type in XML-RPC</link>).</note> To call a method
|
||||
the <nil> type.</note> To call a method
|
||||
on an object, the client simply sends an XML-RPC message to that
|
||||
object. Method calls must match the parameters as defined in
|
||||
the method definition returned by the <describe>
|
||||
|
|
|
|||
|
|
@ -41,10 +41,10 @@
|
|||
<p>The increasing penetration of pen-based devices, such as PDAs and tablet PCs, makes the need for a protocol that allows for sending freehand drawing information more urgent.</p>
|
||||
<p>Several attempts have been made to create a whiteboarding protocol for Jabber:</p>
|
||||
<ol>
|
||||
<li>Collaborative Imaging (Whiteboarding via Streaming XPM) <note>XPM over Jabber (<link url="http://docs.jabber.org/draft-proto/html/sxpm.html">http://docs.jabber.org/draft-proto/html/sxpm.html</link>)</note> describes a protocol that sends partial bitmaps. This protocol is not suitable for freehand drawing and has not been implemented.</li>
|
||||
<li>Collaborative Imaging (Whiteboarding via Streaming XPM) describes a protocol that sends partial bitmaps. This protocol is not suitable for freehand drawing and has not been implemented.</li>
|
||||
<li>Jabber Whiteboarding using SVG <note>Jabber Whiteboarding using SVG <link url="http://www.protocol7.com/jabber/whiteboard_proposal.txt">http://www.protocol7.com/jabber/whiteboard_proposal.txt</link></note> describes a protocol that uses a subset of SVG. It refers to a missing DTD that describes the precise subset, but there is little doubt that that subset will be hard to implement. This protocol has not been implemented.</li>
|
||||
<li>Coccinella <note>Coccinella Project Information - JabberStudio <link url="http://www.jabberstudio.org/projects/coccinella/project/view.php">http://www.jabberstudio.org/projects/coccinella/project/view.php</link></note> is an open source implementation of a whiteboarding protocol. However, the protocol has not been documented and does not seem easy to implement. In fact it is mostly raw TCL, making an implementation of that protocol in a language other than TCL rather difficult.</li>
|
||||
<li>Tkabber <note>Tkabber Project Information - JabberStudio <link url="http://http://www.jabberstudio.org/projects/tkabber/project/view.php">http://www.jabberstudio.org/projects/tkabber/project/view.php</link></note> has a whiteboard plugin. The protocol has not been documented, but it uses a subset of SVG, similar to the one defined in this document.</li>
|
||||
<li>The Coccinella client includes an open source implementation of a whiteboarding protocol. However, the protocol has not been documented and does not seem easy to implement. In fact it is mostly raw TCL, making an implementation of that protocol in a language other than TCL rather difficult.</li>
|
||||
<li>The Tkabber client has a whiteboard plugin. The protocol has not been documented, but it uses a subset of SVG, similar to the one defined in this document.</li>
|
||||
</ol>
|
||||
</section1>
|
||||
<section1 topic='Requirements'>
|
||||
|
|
@ -184,7 +184,7 @@
|
|||
<p>One issue that will hinder all whiteboard protocol implementations is the karma problem. At least jabberd uses karma to make sure that a client does not send to much data to the server. This should help against denial-of-service attacks. When you use up all your karma, the server stops handling your messages for a while. This is a problem for whiteboards because it is much easier to send a lot of drawing data, than to send a lot of textual data. Usually combining paths, that is, sending paths when the user clicks on a send button instead of on mouse up, reduces data size because it reduces the overhead of the message element. Using the relative lineto command ('l') instead of the absolute lineto ('L') command will also reduce message size, because usually relative coordinates will only use one or two digits whereas absolute coordinates will typically use three. Finally implementations can reduce message size by not recording every mouse move event, e.g. by dropping mouse events whose locations would be accurately interpolated.</p>
|
||||
</section2>
|
||||
<section2 topic='Text'>
|
||||
<p>The protocol does not provide explicit support for drawing text. The reason for this is that explicit support, eg. in the form of the SVG text element <note>Text - SVG 1.0 <link url="http://www.w3.org/TR/SVG/text.html">http://www.w3.org/TR/SVG/text.html</link></note>, would break the second and third requirements above. However a client can still provide text support by representing characters as paths, eg. by using a Hershey font <note>Hershey vector font<link url="http://astronomy.swin.edu.au/~pbourke/other/hershey/">http://astronomy.swin.edu.au/~pbourke/other/hershey/</link></note></p>
|
||||
<p>The protocol does not provide explicit support for drawing text. The reason for this is that explicit support, eg. in the form of the SVG text element <note>Text - SVG 1.0 <link url="http://www.w3.org/TR/SVG/text.html">http://www.w3.org/TR/SVG/text.html</link></note>, would break the second and third requirements above. However a client can still provide text support by representing characters as paths, eg. by using a Hershey font.</note></p>
|
||||
<p>The code snippet below shows the lines along which this could be done:</p>
|
||||
<example caption='Coding the letter A into a path'><![CDATA[
|
||||
// generating the path <path d='M14 6l-8,21M14 6l8,21M9 20l10,0'/> from the letter 'A'
|
||||
|
|
|
|||
|
|
@ -306,7 +306,7 @@
|
|||
</iq>]]>
|
||||
</example>
|
||||
|
||||
<p>The example avatar data above will be interpreted by the avatar engine, which registered for the MIME type 'avatar/comic'. This is a sample implementation of an animated avatar. The data states that an animation file shall be loaded from <link url="http://avatar.vp.bluehands.de/comic/lluna.xml">http://avatar.vp.bluehands.de/comic/lluna.xml</link> and then the character config shall be applied modifying the colors of the character definition.</p>
|
||||
<p>The example avatar data above will be interpreted by the avatar engine, which registered for the MIME type 'avatar/comic'. This is a sample implementation of an animated avatar. The data states that an animation file shall be loaded from http://avatar.vp.bluehands.de/comic/lluna.xml and then the character config shall be applied modifying the colors of the character definition.</p>
|
||||
|
||||
<p>The design is particular targeted at existing online games as avatar providers. It would be very easy to adapt the avatar rendering of an online role playing game (MMORPG) or any other community so that it provides avatar images for the VP client. In this case the avatar data would probably only consist of the online accout ID. This is up to the implementation. We imagine such avatar data to be like:</p>
|
||||
|
||||
|
|
@ -320,7 +320,7 @@
|
|||
|
||||
<p>... and the plug-in (which is part or the game distribution) connects to the game server, fetches the configuration, and renders Juliet as an nightelve mage level 30 with all insignia on the web page of Romeo. Romeo is very impressed, falls in love instantly and they both die in the course of a tragic story. Provided that Romeo happens to have the same gaming engine installed. Having not might save him in this time.</p>
|
||||
|
||||
<p>Note: As a matter of fact, we propose a call level plug-in interface described at <note><link url='http://developer.lluna.de/docs/animated-avatars.html'>http://developer.lluna.de/docs/animated-avatars.html</link></note> for advanced avatars.</p>
|
||||
<p>Note: As a matter of fact, we propose a call level plug-in interface formerly described at http://developer.lluna.de/docs/animated-avatars.html for advanced avatars.</p>
|
||||
|
||||
<p>Note: To make things simple for the implementation users may have 2 avatars. The first avatar ('storage:client:avatar') is restricted to GIF and PNG images. The second avatar is fully featured, but optional. It is accessed through the namespace 'storage:client:avatar2' and tracked through digest 'firebat:avatar2:digest'. VP clients must implement 'storage:client:avatar' and 'firebat:avatar:digest' with at least PNG support. They may implement 'storage:client:avatar2' and 'firebat:avatar2:digest'. The scheme can be extended with higher numbers. </p>
|
||||
|
||||
|
|
@ -526,7 +526,7 @@ as part of:
|
|||
<location>...</location> <!-- default location -->
|
||||
</vpi>]]></example>
|
||||
|
||||
<p>Examples are available at <note><link url="http://developer.lluna.de/docs/vpi-file-syntax.html">http://developer.lluna.de/docs/vpi-file-syntax.html</link></note></p>
|
||||
<p>Examples were formerly available at http://developer.lluna.de/docs/vpi-file-syntax.html</p>
|
||||
|
||||
</section2>
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@
|
|||
@
|
||||
U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 .org</code>
|
||||
<p>In this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID. <note>Naturally, there is no way to distinguish with full certainty which is the fake JID and which is the real JID. For example, in some communication contexts, the Cherokee JID may be the real JID and the US-ASCII JID may thus appear to be the fake JID.</note></p>
|
||||
<p>By contrast with address forging, it may be relatively easy to mimic (some) JIDs in Jabber/XMPP systems, especially because JIDs can contain almost any Unicode character. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing. <note>Phishing has been defined as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them" (see <link url='http://fstc.org/projects/counter-phishing-phase-1/'>Financial Services Technology Consortium Counter-Phishing Initiative: Phase I</link>). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.</note> To combat those vulnerabilities, this document recommends a set of best practices to minimize the potential impact of address mimicking on the Jabber/XMPP network. <note>This document does not cover handling of non-XMPP addresses, for example HTTP URLs. Jabber/XMPP clients SHOULD handle such addresses in accordance with best practices for the relevant non-XMPP technology.</note></p>
|
||||
<p>By contrast with address forging, it may be relatively easy to mimic (some) JIDs in Jabber/XMPP systems, especially because JIDs can contain almost any Unicode character. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing. <note>Phishing has been defined by the Financial Services Technology Consortium Counter-Phishing Initiative as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them"). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.</note> To combat those vulnerabilities, this document recommends a set of best practices to minimize the potential impact of address mimicking on the Jabber/XMPP network. <note>This document does not cover handling of non-XMPP addresses, for example HTTP URLs. Jabber/XMPP clients SHOULD handle such addresses in accordance with best practices for the relevant non-XMPP technology.</note></p>
|
||||
</section1>
|
||||
<section1 topic='Recommendations' anchor='rec'>
|
||||
<section2 topic='Presentation of JIDs' anchor='rec-jids'>
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@
|
|||
<li>Make it relatively easy to implement support in standard Jabber/XMPP clients.</li>
|
||||
<li>Where communication with non-XMPP (indeed, non-material) entities is needed, push as much complexity as possible onto gateways between this world and the spirit world.</li>
|
||||
</ol>
|
||||
<p>Note: Whether or not an ESP stream can be established depends on the user's native telepathic abilities as well as acquired telepathic skills such as grounding, centering, pinging, pulse-sending, broadcasting, scanning, probing, suggestion, and projection. <note>For a good introduction to telepathic skills, see <cite>The Telepathy Manual</cite> at <<link url='http://www.psipog.net/articles.php?cat=10131'>http://www.psipog.net/articles.php?cat=10131</link>>.</note> Your mileage may vary.</p>
|
||||
<p>Note: Whether or not an ESP stream can be established depends on the user's native telepathic abilities as well as acquired telepathic skills such as grounding, centering, pinging, pulse-sending, broadcasting, scanning, probing, suggestion, and projection. <note>For a good introduction to telepathic skills, see <cite>The Telepathy Manual</cite> located at <<link url='http://www.psipog.net/art-telepathy-manual.html'>http://www.psipog.net/art-telepathy-manual.html</link>>.</note> Your mileage may vary.</p>
|
||||
</section1>
|
||||
<section1 topic='Protocol Description' anchor='protocol'>
|
||||
<section2 topic='Transport Initiation' anchor='protocol-initiate'>
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Background' anchor='background'>
|
||||
<p>The "LZW" compression algorithm was originally developed by Abraham Lempel and Jacob Ziv, subsequently improved by Terry Welch <note>See "A Technique for High-Performance Data Compression", <cite>Computer</cite> (June 1984), pp. 8-19.</note>, and patented by Sperry Corporation (later Unisys Corporation) as U.S. Patent Number 4,464,650 <note>See <<link url='http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,464,650'>http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,464,650</link>>.</note>. This patent expired on June 20, 2003 <note>See <<link url='http://www.unisys.com/about__unisys/lzw'>http://www.unisys.com/about__unisys/lzw</link>>.</note>. Therefore implementations of LZW are no longer patent-encumbered.</p>
|
||||
<p>The "LZW" compression algorithm was originally developed by Abraham Lempel and Jacob Ziv, subsequently improved by Terry Welch <note>See "A Technique for High-Performance Data Compression", <cite>Computer</cite> (June 1984), pp. 8-19.</note>, and patented by Sperry Corporation (later Unisys Corporation) as U.S. Patent Number 4,464,650 <note>See <<link url='http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,464,650'>http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,464,650</link>>.</note>. This patent expired on June 20, 2003 <note>See <<link url='http://compression-links.info/Link/1264_LZW_Patent_Expiration.htm'>http://compression-links.info/Link/1264_LZW_Patent_Expiration.htm</link>> and <note>See <<link url='http://compression-links.info/Link/1814_LZW_Patent_Expiration.htm'>http://compression-links.info/Link/1814_LZW_Patent_Expiration.htm</link>>.</note>. Therefore implementations of LZW are no longer patent-encumbered.</p>
|
||||
<p>The algorithm is specified by Ecma International in &ecma151; under the name "DCLZ".</p>
|
||||
</section1>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue