From 6e921e3d8832e30fcdad09332a339f45039f8dc0 Mon Sep 17 00:00:00 2001 From: Unknown User Date: Mon, 14 Sep 2009 15:55:28 +0000 Subject: [PATCH] fixed dead links /psa git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3420 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0006.xml | 4 ++-- xep-0008.xml | 2 +- xep-0009.xml | 2 +- xep-0010.xml | 6 +++--- xep-0019.xml | 4 ++-- xep-0021.xml | 2 +- xep-0024.xml | 1 - xep-0038.xml | 2 +- xep-0043.xml | 2 +- xep-0057.xml | 2 +- xep-0071.xml | 2 +- xep-0072.xml | 5 ++--- xep-0074.xml | 2 +- xep-0075.xml | 4 +--- xep-0113.xml | 8 ++++---- xep-0151.xml | 6 +++--- xep-0165.xml | 2 +- xep-0183.xml | 2 +- xep-0229.xml | 2 +- 19 files changed, 28 insertions(+), 32 deletions(-) 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.

@@ -91,6 +91,6 @@

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.

 diff --git a/xep-0008.xml b/xep-0008.xml index 27a21593..04e0603b 100644 --- a/xep-0008.xml +++ b/xep-0008.xml @@ -92,7 +92,7 @@

There are two methods for retrieving the actual avatar data:

  1. An exchange between clients of <iq/> elements in the jabber:iq:avatar namespace
    2. -
  2. Public XML storage from the avatar-generating client to the server and public XML retrieval from the server to the avatar-requesting client Refer to the Generic XML Namespace Storage draft protocol.
    3. +
  3. 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;).

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 Whenever possible, the avatar-requesting client should attempt to determine if the avatar-generating client has an avatar available before requesting it. 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.:

diff --git a/xep-0009.xml b/xep-0009.xml index 43252fe1..f5424c4a 100644 --- a/xep-0009.xml +++ b/xep-0009.xml @@ -57,7 +57,7 @@

&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 element as opposed to an &IQ; stanza), resulting in potential interoperability problems.

-

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 XPM over Jabber (http://docs.jabber.org/draft-proto/html/sxpm.html). 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 Conferencing protocol draft (http://jabber.org/?oid=1538).

+

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 Distributed SVG documents (http://www.jabber.org/?oid=1025) SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt) Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/) to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.

+

There are today at least four different attempts "Distributed SVG documents" (formerly at http://www.jabber.org/?oid=1025) SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt) Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/) to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.

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 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 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.

+

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 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.

&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 @@
  • Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.
  • 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. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). 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.
    • -

    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. 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 http://www.jabber.org/bylaws.html.)

    +

    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. 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 http://www.jabber.org/bylaws.html.)

     diff --git a/xep-0021.xml b/xep-0021.xml index d309f8e1..8d1247d1 100644 --- a/xep-0021.xml +++ b/xep-0021.xml @@ -59,7 +59,7 @@

    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.

     diff --git a/xep-0024.xml b/xep-0024.xml index b0f640be..86f2c83f 100644 --- a/xep-0024.xml +++ b/xep-0024.xml @@ -46,7 +46,6 @@

    Pubsub ("publish/subscribe") is a technique for coordinating the efficient delivery of information from publisher to consumer. This specification -An earlier draft of this specification can be found at http://www.pipetree.com/testwiki/JabberPubsubSpec. describes the use of pubsub within a Jabber context and is a result of two separate but related goals:

    diff --git a/xep-0038.xml b/xep-0038.xml index 5dc4ed78..cc332ecc 100644 --- a/xep-0038.xml +++ b/xep-0038.xml @@ -58,7 +58,7 @@

    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.

     diff --git a/xep-0043.xml b/xep-0043.xml index 9085bfd0..3321bfad 100644 --- a/xep-0043.xml +++ b/xep-0043.xml @@ -23,7 +23,7 @@ 0.2 2003-10-20 psa - At the request of the author, changed status to Retracted; interested parties should refer to <http://www.openaether.org/projects/jabber_database.html> for further information. + At the request of the author, changed status to Retracted. 0.1 diff --git a/xep-0057.xml b/xep-0057.xml index 019e402b..aa02fece 100644 --- a/xep-0057.xml +++ b/xep-0057.xml @@ -57,7 +57,7 @@ -

    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;.

    ]]> diff --git a/xep-0071.xml b/xep-0071.xml index b44edb23..5e801f53 100644 --- a/xep-0071.xml +++ b/xep-0071.xml @@ -832,7 +832,7 @@ That seems fine to me.

    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 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 Financial Services Technology Consortium Counter-Phishing Initiative: Phase I)., an implementation MAY choose to:

    +

    To reduce the risk of phishing attacks 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"., an implementation MAY choose to:

    • Display the value of the XHTML 'href' attribute instead of the XML character data of the <a/> element.
    • 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.
      • diff --git a/xep-0072.xml b/xep-0072.xml index b2a828e1..07645eca 100644 --- a/xep-0072.xml +++ b/xep-0072.xml @@ -122,7 +122,7 @@

      &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 WS-Routing Specification <http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp>. and WS-Referral WS-Referral Specification <http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp>., 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.

      +

      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.)

       @@ -1087,8 +1087,7 @@ -

      SOAP has been supplemented by several support protocols that help ensure message integrity and confidentiality (WS-Security WS-Security <http://msdn.microsoft.com/ws/2002/04/Security/>.) as well as transaction management for failing message exchanges (WS-Transaction - WS-Transaction <http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transaction.asp>.). 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;.

      +

      SOAP has been supplemented by several support protocols that help ensure message integrity and confidentiality (WS-Security WS-Security <http://msdn.microsoft.com/ws/2002/04/Security/>.) as well as transaction management for failing message exchanges (see WS-Transaction). 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;.

       diff --git a/xep-0074.xml b/xep-0074.xml index 9cdca022..1d91e100 100644 --- a/xep-0074.xml +++ b/xep-0074.xml @@ -28,7 +28,7 @@ 0.2 2003-10-20 psa - At the request of the author, changed status to Retracted; interested parties should refer to <http://www.openaether.org/projects/sac.html> for further information. + At the request of the author, changed status to Retracted. 0.1 diff --git a/xep-0075.xml b/xep-0075.xml index 463550f4..5a7ccbac 100644 --- a/xep-0075.xml +++ b/xep-0075.xml @@ -1091,9 +1091,7 @@

      Method calls in JOAP are simply XML-RPC calls, as defined in XEP-0009.XEP-0009 leaves some open questions as to use of widely-defined extensions to the XML-RPC standard, such as - the <nil> type (see - <nil> - data type in XML-RPC). To call a method + the <nil> type. 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> diff --git a/xep-0113.xml b/xep-0113.xml index e71bc6c7..f7e697b4 100644 --- a/xep-0113.xml +++ b/xep-0113.xml @@ -41,10 +41,10 @@

      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:

        -
      1. Collaborative Imaging (Whiteboarding via Streaming XPM) XPM over Jabber (http://docs.jabber.org/draft-proto/html/sxpm.html) describes a protocol that sends partial bitmaps. This protocol is not suitable for freehand drawing and has not been implemented.
        2. +
      2. 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.
      3. Jabber Whiteboarding using SVG Jabber Whiteboarding using SVG http://www.protocol7.com/jabber/whiteboard_proposal.txt 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.
        4. -
      4. Coccinella Coccinella Project Information - JabberStudio http://www.jabberstudio.org/projects/coccinella/project/view.php 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.
        5. -
      5. Tkabber Tkabber Project Information - JabberStudio http://www.jabberstudio.org/projects/tkabber/project/view.php 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.
        6. +
      6. 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.
        7. +
      7. 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.
       @@ -184,7 +184,7 @@

      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 Text - SVG 1.0 http://www.w3.org/TR/SVG/text.html, 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 Hershey vector fonthttp://astronomy.swin.edu.au/~pbourke/other/hershey/

      +

      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 Text - SVG 1.0 http://www.w3.org/TR/SVG/text.html, 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.

      The code snippet below shows the lines along which this could be done:

      from the letter 'A' diff --git a/xep-0151.xml b/xep-0151.xml index 98a87a2a..e2d37e21 100644 --- a/xep-0151.xml +++ b/xep-0151.xml @@ -306,7 +306,7 @@ ]]> -

      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 http://developer.lluna.de/docs/animated-avatars.html for advanced avatars.

      +

      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 http://developer.lluna.de/docs/vpi-file-syntax.html

      +

      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 .org

      In this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID. 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.

      -

      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. 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 Financial Services Technology Consortium Counter-Phishing Initiative: Phase I). 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. 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. 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.

      +

      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. 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. 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. 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.

       diff --git a/xep-0183.xml b/xep-0183.xml index 8e06ec02..b74a7998 100644 --- a/xep-0183.xml +++ b/xep-0183.xml @@ -41,7 +41,7 @@
    • Make it relatively easy to implement support in standard Jabber/XMPP clients.
    • 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.
      • -

      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. For a good introduction to telepathic skills, see The Telepathy Manual at <http://www.psipog.net/articles.php?cat=10131>. Your mileage may vary.

      +

      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. For a good introduction to telepathic skills, see The Telepathy Manual located at <http://www.psipog.net/art-telepathy-manual.html>. Your mileage may vary.

       diff --git a/xep-0229.xml b/xep-0229.xml index a6299c02..ca771701 100644 --- a/xep-0229.xml +++ b/xep-0229.xml @@ -40,7 +40,7 @@ -

      The "LZW" compression algorithm was originally developed by Abraham Lempel and Jacob Ziv, subsequently improved by Terry Welch See "A Technique for High-Performance Data Compression", Computer (June 1984), pp. 8-19., and patented by Sperry Corporation (later Unisys Corporation) as U.S. Patent Number 4,464,650 See <http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,464,650>.. This patent expired on June 20, 2003 See <http://www.unisys.com/about__unisys/lzw>.. Therefore implementations of LZW are no longer patent-encumbered.

      +

      The "LZW" compression algorithm was originally developed by Abraham Lempel and Jacob Ziv, subsequently improved by Terry Welch See "A Technique for High-Performance Data Compression", Computer (June 1984), pp. 8-19., and patented by Sperry Corporation (later Unisys Corporation) as U.S. Patent Number 4,464,650 See <http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,464,650>.. This patent expired on June 20, 2003 See <http://compression-links.info/Link/1264_LZW_Patent_Expiration.htm> and See <http://compression-links.info/Link/1814_LZW_Patent_Expiration.htm>.. Therefore implementations of LZW are no longer patent-encumbered.

      The algorithm is specified by Ecma International in &ecma151; under the name "DCLZ".