From 39e3ea4b7d0758247decee91d39b5c2f21a215e1 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 4 Oct 2006 02:19:05 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@37 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0080.xml | 40 ++++++++++++++++++++-------------------- xep-0081.xml | 40 ++++++++++++++++++++-------------------- xep-0082.xml | 34 +++++++++++++++++----------------- xep-0083.xml | 28 ++++++++++++++-------------- xep-0084.xml | 36 ++++++++++++++++++------------------ xep-0085.xml | 40 ++++++++++++++++++++-------------------- xep-0086.xml | 10 +++++----- xep-0087.xml | 34 +++++++++++++++++----------------- xep-0088.xml | 30 +++++++++++++++--------------- xep-0089.xml | 16 ++++++++-------- 10 files changed, 154 insertions(+), 154 deletions(-) diff --git a/xep-0080.xml b/xep-0080.xml index 7ca678e7..d3ea3ea5 100644 --- a/xep-0080.xml +++ b/xep-0080.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
User Geolocation This document defines an XMPP protocol extension for communicating information about the current geographical location of an entity. @@ -15,13 +15,13 @@ Standards JIG XMPP Core - JEP-0060 + XEP-0060 geoloc - http://jabber.org/protocol/geoloc/geoloc.xsd + http://www.xmpp.org/schemas/geoloc.xsd &hildjj; &stpeter; @@ -29,7 +29,7 @@ 1.3 2006-08-21 psa -

Folded in civil location from JEP-0112.

 +

Folded in civil location from XEP-0112.

 1.2 @@ -65,13 +65,13 @@ 0.7 2004-04-25 psa -

Corrected several errors; added reference to JEP-0033.

 +

Corrected several errors; added reference to XEP-0033.

 0.6 2004-02-19 psa -

Reverted from infobits to geoloc elements; moved physical address protocol back to JEP-0112.

 +

Reverted from infobits to geoloc elements; moved physical address protocol back to XEP-0112.

 0.5 @@ -83,7 +83,7 @@ 0.4 2003-09-08 psa -

Merged in contents of JEP-0112.

 +

Merged in contents of XEP-0112.

 0.3 @@ -237,16 +237,16 @@ timestamp xs:datetime - UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of &jep0082;) + UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of &xep0082;) 2004-02-19T21:12Z

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

-

The location information SHOULD be communicated by means of &jep0060; or the subset of pubsub defined in &jep0163;. Because location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;, although an application MAY do so if necessary.

+

The location information SHOULD be communicated by means of &xep0060; or the subset of pubsub defined in &xep0163;. Because location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;, although an application MAY do so if necessary.

-

In order to provide information about one's location, the publishing entity should use the pubsub protocol (the following examples show use of the publish-subscribe subset specified in JEP-0163).

+

In order to provide information about one's location, the publishing entity should use the pubsub protocol (the following examples show use of the publish-subscribe subset specified in XEP-0163).

id='publish1'> @@ -365,7 +365,7 @@

  • The Wireless Village (now "IMPS") specifications for mobile instant messaging; these specifications define a presence attribute for address information as encapsulated in the IMPS "Address" element The Wireless Village Initiative: Presence Attributes v1.1 (WV-029); for further information, visit <http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html>..

  • The SIP-based SIMPLE specifications; in particular, the IETF's GEOPRIV Working Group has defined an extension to the IETF's &pidf; for location information, as specified in &rfc4119; (also known as "PIDF-LO").

    • -

    The following table also maps the format defined herein to the vCard XML format specified in &jep0054;.

    +

    The following table also maps the format defined herein to the vCard XML format specified in &xep0054;.

    @@ -378,7 +378,7 @@ @@ -442,7 +442,7 @@ @@ -467,10 +467,10 @@ -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; includes 'http://jabber.org/protocol/geoloc' to its registry of protocol namespaces.

     @@ -489,7 +489,7 @@ The protocol documented by this schema is defined in - JEP-0080: http://www.jabber.org/jeps/jep-0080.html + XEP-0080: http://www.xmpp.org/extensions/xep-0080.html @@ -521,4 +521,4 @@ ]]>     - + diff --git a/xep-0081.xml b/xep-0081.xml index 4027019e..0cb0ec22 100644 --- a/xep-0081.xml +++ b/xep-0081.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
    Jabber MIME Type - This JEP specifies a MIME type for launching a Jabber client as a helper application from most modern web browsers, and for completing basic use cases once the client is launched. + This document specifies a MIME type for launching a Jabber client as a helper application from most modern web browsers, and for completing basic use cases once the client is launched. &LEGALNOTICE; 0081 Retracted @@ -18,8 +18,8 @@ XMPP IM RFC 2045 RFC 3023 - JEP-0045 - JEP-0077 + XEP-0045 + XEP-0077 None None @@ -62,7 +62,7 @@

    Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach See, for instance, <http://www.mozilla.org/docs/web-developer/mimetypes.html> for information about MIME support in the Mozilla family of web browsers. is to define a MIME type (in accordance with &rfc2045;) and then reconfigure the relevant server and client software to correctly handle the new MIME type.

    -

    Therefore, this JEP defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.

    +

    Therefore, this document defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.

    Note: The "application/jabber+xml" MIME type defined herein is not to be confused with the "application/xmpp+xml" MIME type defined in &rfc3923;; the two MIME types address different requirements and do not overlap or conflict.

    @@ -77,8 +77,8 @@
  • Join a groupchat room.
  • Register with a service.
    • @@ -118,7 +118,7 @@ ]]> -

    The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &jep0045;, first authenticating with the user's Jabber/XMPP server if necessary.

    +

    The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &xep0045;, first authenticating with the user's Jabber/XMPP server if necessary.

    ]]> -

    The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &jep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in JEP-0077.

    +

    The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in XEP-0077.

     ACTIVE <--> COMPOSING

    Note: All four of the states shown may transition to the GONE state.

     -

    If an entity supports the Chat State Notifications protocol, it MUST advertise that fact in its responses to &jep0030; information ("diso#info") requests by returning a feature of "http://jabber.org/protocol/chatstates":

    +

    If an entity supports the Chat State Notifications protocol, it MUST advertise that fact in its responses to &xep0030; information ("diso#info") requests by returning a feature of "http://jabber.org/protocol/chatstates":

    ACTIVE <--> COMPOSING ]]> -

    In addition, support for the Chat States Notification protocol can be determined through the dynamic profile of Service Discovery defined in &jep0115;.

    +

    In addition, support for the Chat States Notification protocol can be determined through the dynamic profile of Service Discovery defined in &xep0115;.

     -

    Before generating chat state notifications, a User SHOULD explicitly discover whether the Contact supports the protocol defined herein (as described in the Discovering Support section of this document) or explicitly negotiate the use of chat state notifications with the Contact (via &jep0155;).

    +

    Before generating chat state notifications, a User SHOULD explicitly discover whether the Contact supports the protocol defined herein (as described in the Discovering Support section of this document) or explicitly negotiate the use of chat state notifications with the Contact (via &xep0155;).

    In the absence of explicit discovery or negotiation, the User MAY implicitly request and discover the use of chat state notifications in a one-to-one chat session by adhering to the following business rules:

    1. If the User desires chat state notifications, the initial content message sent to the Contact MUST contain a chat state notification extension, which SHOULD be <active/>.
      2. @@ -264,7 +264,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
    XMPP<Country/> <country/> <CTRY/> - As noted in JEP-0054, the XML vCard format defined in draft-dawson-vcard-xml-dtd-01 specified a <COUNTRY/> element rather than a <CTRY/> element; refer to JEP-0054 for details. + As noted in XEP-0054, the XML vCard format defined in draft-dawson-vcard-xml-dtd-01 specified a <COUNTRY/> element rather than a <CTRY/> element; refer to XEP-0054 for details.
    -- <Accuracy/> - This element provides accuracy in meters. The geolocation protocol defined in JEP-0080 specifies such an element for XMPP, which SHOULD be used when mapping from IMPS to XMPP. + This element provides accuracy in meters. The geolocation protocol defined in XEP-0080 specifies such an element for XMPP, which SHOULD be used when mapping from IMPS to XMPP. -- --

    A client MUST allow the user to configure whether he or she wants to send chat state notifications.

    -

    Note: Support for only <active/> and <composing/> is functionally equivalent to supporting the Composing event from JEP-0022.

    +

    Note: Support for only <active/> and <composing/> is functionally equivalent to supporting the Composing event from XEP-0022.

    Even if the user types continuously for a long time (e.g., while composing a lengthy reply), the client MUST NOT send more than one standalone <composing/> notification in a row. More generally, a client MUST NOT send a second instance of any given standalone notification (i.e., a standalone notification MUST be followed by a different state, not repetition of the same state). However, every content message SHOULD contain an <active/> notification.

    @@ -278,7 +278,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING     -

    Chat state notifications MAY be sent in the context of groupchat rooms (e.g., as defined in &jep0045;). The following business rules apply:

    +

    Chat state notifications MAY be sent in the context of groupchat rooms (e.g., as defined in &xep0045;). The following business rules apply:

    1. A client MAY send chat state notifications even if not all room occupants do so.
    2. A client SHOULD NOT generate <gone/> notifications.
      3. @@ -302,7 +302,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
    -

    Servers in constrained network environments (e.g., serving small-footprint clients via &jep0025; or &jep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to JEP-0022, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.

    +

    Servers in constrained network environments (e.g., serving small-footprint clients via &xep0025; or &xep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to XEP-0022, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.

         @@ -512,9 +512,9 @@ INACTIVE <--> ACTIVE <--> COMPOSING

    The states of a chat thread may reveal information about a user's interaction with his or her computer, including his or her physical presence; such information SHOULD NOT be revealed to conversation partners who are not trusted to know such information. Client implementations MUST provide a mechanism that enables the user to disable chat state notifications if desired.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; includes 'http://jabber.org/protocol/chatstates' in its registry of protocol namespaces.

     @@ -532,7 +532,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING The protocol documented by this schema is defined in - JEP-0085: http://www.jabber.org/jeps/jep-0085.html + XEP-0085: http://www.xmpp.org/extensions/xep-0085.html @@ -551,4 +551,4 @@ INACTIVE <--> ACTIVE <--> COMPOSING ]]>     - + diff --git a/xep-0086.xml b/xep-0086.xml index 3c5c8b67..ab602063 100644 --- a/xep-0086.xml +++ b/xep-0086.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Error Condition Mappings A mapping to enable legacy entities to correctly handle errors from XMPP-aware entities. @@ -344,4 +344,4 @@

    Mapping legacy error codes to XMPP-style errors is an inexact science, and there are likely to be inconsistencies in some places. However, it is the authors' belief that the mapping presented in this document will be adequate for the majority of cases, and will help smooth the migration to XMPP-compliant implementations.

     - + diff --git a/xep-0087.xml b/xep-0087.xml index db40cff5..6af4cce0 100644 --- a/xep-0087.xml +++ b/xep-0087.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Stream Initiation A common method to initiate a stream with meta information @@ -13,9 +13,9 @@ Retracted Standards Track Standards JIG - JEP-0030 + XEP-0030 None - JEP-0095 + XEP-0095 si Thomas @@ -33,7 +33,7 @@

    As more people begin to make use of streams in Jabber, there becomes a need - for more descriptive negotiation of which stream to use. This JEP provides + for more descriptive negotiation of which stream to use. This document provides a method to negotiate a stream and provide some meta-information about the streams usage.

    @@ -91,7 +91,7 @@

    Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they - wish to use. This is discovered by using &jep0030;: + wish to use. This is discovered by using &xep0030;:

    The Receiver will advertise the "http://jabber.org/protocol/si" namespace as - a feature to represent they implement this JEP. The specific profiles can + a feature to represent they implement this document. The specific profiles can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile: @@ -302,16 +302,16 @@ <si> profile attribute. Next, the information for the headers is decided upon. Each piece of information will be transported in a <header> tag. The name attribute is a descriptive key that can be - looked up at the Jabber Registrar or JEP describing the profile. The + looked up at the XMPP Registrar or XEP describing the profile. The actual data in the <header> is the fact related to the name attribute. It must also be stated whether the header is required or optional.

    - This JEP does not define any profiles, nor does it place any restrictions - on what type of information a profile should detail. This JEP also does + This document does not define any profiles, nor does it place any restrictions + on what type of information a profile should detail. This document also does not place restrictions on what may be placed in a <header>. Other - JEPs will define profiles to be used with Stream Initiation. + XEPs will define profiles to be used with Stream Initiation.

    @@ -320,7 +320,7 @@ provide many benefits. In order to fully appreciate these benefits, streams must link the Stream Initiation to the stream. The id attribute of the <si> node is intended to provide this link. It is - out of scope of this JEP to define how streams will make use of this + out of scope of this document to define how streams will make use of this facility, but it does suggest some methods:
    • @@ -407,11 +407,11 @@

      - This JEP uses the MIME types as recorded by IANA, but no other direct + This document uses the MIME types as recorded by IANA, but no other direct interaction is necessary.

      - +

      The "http://jabber.org/protocol/si" namespace will be registered. The registrar will track header profiles for different stream initiation @@ -426,4 +426,4 @@

      To follow.

       - + diff --git a/xep-0088.xml b/xep-0088.xml index 79bab270..1f5791ab 100644 --- a/xep-0088.xml +++ b/xep-0088.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      Client Webtabs A protocol for displaying web-based tabs in clients. @@ -15,8 +15,8 @@ Standards JIG XMPP Core - JEP-0030 - JEP-0049 + XEP-0030 + XEP-0049 @@ -37,7 +37,7 @@ 0.3 2003-09-30 red - Moved service discovery to top of use cases, added option for separate webtab provider and added reference to JEP-0101. + Moved service discovery to top of use cases, added option for separate webtab provider and added reference to XEP-0101. 0.2 @@ -56,7 +56,7 @@

      Webtabs are a way for servers to specify a number to web pages which can be used in clients and displayed like the web-based services in Yahoo Messenger, MSN Messenger and JIM. This enables a server administrator to easily create services for Jabber clients and also help to integrate Jabber clients with existing web-based applications.

      -

      The motivations for this JEP are:

      +

      The motivations for this document are:

      • To enable servers to specify a selection of web-based services for use in a client.
      • To allow easy integration with existing web-based systems.
        • @@ -66,7 +66,7 @@ -

        &jep0030; SHALL be used for discovering support for webtabs on servers.

        +

        &xep0030; SHALL be used for discovering support for webtabs on servers.

        ]]>

        The webtab contains CDATA which is the URL of the webtab, the webtab is an HTML page retrieved from an HTTP server using a standard browser which you embed into your client UI using a technique such as the IWebBrowser2 control interface on windows which allows you to embed either the IE or Gecko engines depending on what you have installed, this data is REQUIRED.

        -

        The "type" attribute tells the client what the service being provided is, this allows a client to display icons on the tabs to represent them, handling of the type in clients is OPTIONAL, inclusion of this attribute is REQUIRED (See "Jabber Registrar Considerations" for examples of values for this attribute).

        +

        The "type" attribute tells the client what the service being provided is, this allows a client to display icons on the tabs to represent them, handling of the type in clients is OPTIONAL, inclusion of this attribute is REQUIRED (See "XMPP Registrar Considerations" for examples of values for this attribute).

        The "name" attribute is the offical name of a particular service this can be displayed as the tab name, this attribute is REQUIRED.

        The "id" attribute is a unique identifier for a service which you can use to refer to it later, used for when using private storage to store a preference to which tabs should be visible, this attribute is REQUIRED.

         -

        &jep0049; SHALL be used for storing webtab preferences.

        +

        &xep0049; SHALL be used for storing webtab preferences.

        The "visible" attribute tells the client that a tab SHOULD or SHOULD NOT be hidden, a client SHOULD provide an interface for managing the visibility of the tabs and updating the preferences appropriately, this attribute is REQUIRED.

         -

        It is RECOMMENDED that a mechanism such as &jep0101; be used for automatic service authentication.

        +

        It is RECOMMENDED that a mechanism such as &xep0101; be used for automatic service authentication.

                 @@ -178,12 +178,12 @@
      -

      It is recommended that JEP-0101 be used to provide transparent authentication of the webtabs.

      +

      It is recommended that XEP-0101 be used to provide transparent authentication of the webtabs.

      No IANA interaction required.

       - +

      The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/webtab" and possibly the list of offical types will need to be managed too.

      @@ -212,4 +212,4 @@
      - + diff --git a/xep-0089.xml b/xep-0089.xml index 5f732a94..4470be35 100644 --- a/xep-0089.xml +++ b/xep-0089.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      Generic Alerts A protocol for generic alerts (similar to .NET Alerts service). @@ -17,7 +17,7 @@ None None Not yet assigned - + Richard @@ -42,7 +42,7 @@

      Generic Alerts is a way to extend headlines to allow functionality similar to .NET Alerts.

      -

      The motivations for this JEP are:

      +

      The motivations for this document are:

      • To allow services to send alerts to users, e.g. like an auction notifying you when you are outbid or that you have won
      @@ -76,7 +76,7 @@

      No IANA interaction required.

       - +

      The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/alert".

       - +