diff --git a/xep-0006.xml b/xep-0006.xml
index 1e7bc201..5bb5914b 100644
--- a/xep-0006.xml
+++ b/xep-0006.xml
@@ -58,7 +58,7 @@
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. 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 Theoretic Identity website. 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. 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. 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. 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 (http://www.theoretic.com/identity/), 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. 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.
There are two methods for retrieving the actual avatar data:
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
&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.
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
A working session during JabberCon 2001 resulted in a formalisation of a single method. This document describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.
+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.
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.
diff --git a/xep-0010.xml b/xep-0010.xml index 1af90ab5..e9cc2a4c 100644 --- a/xep-0010.xml +++ b/xep-0010.xml @@ -34,8 +34,8 @@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.
-There exists today a protocol draft for sending streaming XPM over Jabber
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
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.
+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.
The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):
@@ -43,7 +43,7 @@A set of requirements that the proposed protocol should fulfill.
There are today at least four different attempts
There are today at least four different attempts
One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.
diff --git a/xep-0019.xml b/xep-0019.xml index 4be1b13c..a3fbc7d9 100644 --- a/xep-0019.xml +++ b/xep-0019.xml @@ -38,7 +38,7 @@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).
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).
&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).
@@ -71,6 +71,6 @@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.
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.
The protocol operates in the 'http://xml.cataclysm.cx/jabber/ens/' namespace.
-A reference implementation is available at http://cataclysm.cx/jabber/ens.html.
+A reference implementation was formerly available at http://cataclysm.cx/jabber/ens.html.
Pubsub ("publish/subscribe") is a technique for coordinating the efficient
delivery of information from publisher to consumer. This specification
-
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.
-Emoticons are the text string 'smiley' or 'frowny' faces such as :-) and :-( 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 'ASCII Art') that serve to replace typing the full word or to simply be cute or creative in the conversation.
+Emoticons are the text string 'smiley' or 'frowny' faces such as :-) and :-( 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 'ASCII Art') that serve to replace typing the full word or to simply be cute or creative in the conversation.
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.
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.
JID, category and type are stored as attributes of <item/> 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 http://www.jabber.org/jana/disco.php.
+JID, category and type are stored as attributes of <item/> tag. Categories and types are the same as in disco. Official categories and types associated with disco are administered by the ®ISTRAR; see &DISCOCATEGORIES;.
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).
To reduce the risk of phishing attacks
To reduce the risk of phishing attacks
&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.
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.
-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 WS-Routing
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 WS-Routing and WS-Referral, 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.
(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 SOAP XMPP Binding.)
SOAP has been supplemented by several support protocols that help ensure message integrity and confidentiality (WS-Security
SOAP has been supplemented by several support protocols that help ensure message integrity and confidentiality (WS-Security
Method calls in JOAP are simply XML-RPC calls, as defined in
XEP-0009.
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.
Several attempts have been made to create a whiteboarding protocol for Jabber:
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.
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
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
The code snippet below shows the lines along which this could be done:
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.
+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.
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:
@@ -320,7 +320,7 @@... 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.
-Note: As a matter of fact, we propose a call level plug-in interface described at
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.
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.
@@ -526,7 +526,7 @@ as part of:Examples are available at
Examples were formerly available at http://developer.lluna.de/docs/vpi-file-syntax.html
diff --git a/xep-0165.xml b/xep-0165.xml index 4aa1aef9..f9b61ff2 100644 --- a/xep-0165.xml +++ b/xep-0165.xml @@ -85,7 +85,7 @@ @ U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 .orgIn this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID.
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.
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: 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: 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.
The "LZW" compression algorithm was originally developed by Abraham Lempel and Jacob Ziv, subsequently improved by Terry Welch
The "LZW" compression algorithm was originally developed by Abraham Lempel and Jacob Ziv, subsequently improved by Terry Welch
The algorithm is specified by Ecma International in &ecma151; under the name "DCLZ".