Summary
The Extensible Messaging and Presence
Protocol (XMPP) is an IETF standard
protocol for exchanging information
between network endpoints using
Extensible Markup Language (XML).
It is used to enable instant messaging
and presence applications and
is growing in popularity. This
document proposes to include XMPP
in the suite of protocols that
is supported in H.350, so that
an organization can directory-enable
and manage XMPP resources in the
same way that other multimedia
protocols (e.g. H.320, H.323,
SIP) are managed in H.350.
Although XMPP is an RFC, the primary
data element that is used to identify
an XMPP entities, the XMPP URI
scheme, is still working its way
through the IETF.
The purpose of this contribution
is to secure this effort as a
work item in Study Group 16 and
to create a text that can be reviewed
within ITU-T and the external
community (e.g. Internet2) with
the expectation that a mature
version of this work will coincide
with the publication by the IETF
of the XMPP URI scheme so that
H.350.7 can be ratified at the
next ITU-T SG16 meeting.
Keywords
LDAP, Directory Services, XMPP,
Instant Messaging, Presence
| Contact: | Tyler Miller Johnson University of North Carolina USA |
Tyler_Johnson@unc.edu |
| Contact: | Nadim El-Khoury |
Nadim_Elkhoury@unc.edu |
Table of Contents
1
Scope
3
1.1
Extending the Schema
3
2
References
3
2.1
Normative References
3
2.2
Non-Normative References
4
3
Definitions
4
4
Abbreviations
4
5
Conventions
4
6
Object Class Definitions
5
6.1
XmppURIObject Object Class
5
6.2
XmppIdentityURI
attribute
5
7
XmppURIObject LDIF Files
6
8
ASN.1 Representation
7
9
DSML Representation
8
Annex A:
Indexing Profile
10
A
Annex
A Indexing Profile
10
I
Electronic Attachment
11
1 Scope
The Extensible Messaging and Presence
Protocol (XMPP) is an IETF standard
protocol for exchanging information
between network endpoints using
Extensible Markup Language (XML).
It is used to enable instant messaging
and presence applications and
is growing in popularity. This
document proposes to include XMPP
in the suite of protocols that
is supported in H.350, so that
an organization can directory-enable
and manage XMPP resources in the
same way that other multimedia
protocols (e.g. H.320, H.323,
SIP) are managed in H.350.
Although XMPP is an RFC, the primary
data element that is used to identify
an XMPP entities, the XMPP URI
scheme, is still working its way
through the IETF.
The purpose of this contribution
is to secure this effort as a
work item in Study Group 16 and
to create a text that can be reviewed
within ITU-T and the external
community (e.g. Internet2) with
the expectation that a mature
version of this work will coincide
with the publication by the IETF
of the XMPP URI scheme so that
H.350.7 can be ratified at the
next ITU-T SG16 meeting.
The scope of this Recommendation
does not include normative methods
for the use of the LDAP directory
itself or the data it contains.
1.1 Extending the Schema
The XmppIdentityURIObject classes
may be extended as necessary for
specific implementations. See
the base H.350 document for a
discussion on schema extension.
2 References
The following ITU-T Recommendations
and other references contain provisions,
which, through reference in this
text, constitute provisions of
this Recommendation. At the time
of publication, the editions indicated
were valid. All Recommendations
and other references are subject
to revision; users of this Recommendation
are therefore encouraged to investigate
the possibility of applying the
most recent edition of the Recommendations
and other references listed below.
A list of the currently valid
ITU-T Recommendations is regularly
published.
The reference to a document within
this Recommendation does not give
it, as a stand-alone document,
the status of a Recommendation
2.1 Normative References
- ITU-T Recommendation H.350 (2003),
Directory Services Architecture
for Multimedia Conferencing.
- ITU-T Recommendation H.350.1
(2003), Directory Services
Architecture for H.323.
- ITU-T Recommendation H.350.2
(2003), Directory Services
Architecture for H.235.
- ITU-T Recommendation H.350.3
(2003), Directory Services
Architecture for H.320.
- ITU-T Recommendation H.350.4
(2003), Directory Services
Architecture for SIP.
- ITU-T Recommendation H.350.5
(2003), Directory Services
Architecture for Non-Standard
Protocols.
- IETF RFC 3920 (2004), Extensible
Messaging and Presence Protocol
(XMPP): Core.
- IETF [draft-saintandre-xmpp-uri-06.txt]
(2004), A Uniform Resource
Identifier (URI) Scheme for the
Extensible Messaging and Presence
Protocol (XMPP). (NOTE: This
document expected to reach RFC
maturity in early 2005)
2.2 Non-Normative References
- Timothy A. Howes, PhD, Mark
C. Smith, Gordon S. Good, New
Riders Publishing (1999), ISBN:
1578700701, Understanding
And Deploying LDAP Directory Services.
- Timothy A. Howes, PhD, Mark
C. Smith, New Riders Publishing
(1997), ISBN: 1578700000,
LDAP Programming Directory-Enabled
Applications with Lightweight
Directory Access Protocol.
3 Definitions
The following terms used throughout
the document:
call server:
a protocol-specific signalling
engine that routes video or voice
calls on the network. In H.323
this entity is a gatekeeper. In
SIP, this entity is a SIP Proxy
Server. Note that not all signalling
protocols use a call server.
commObject: An
LDAP object class defined in ITU-T
H.350 that represents generic
multimedia conferencing endpoints.
endpoint: a logical
device that provides video and/or
voice media encoding/decoding,
and signalling functions. Examples
include:
1.
a group teleconferencing appliance
that is located in a conference
room
2.
an IP telephone.
3.
a software program that takes
video and voice from a camera
and microphone and encodes it
and applies signalling using a
host computer.
Note that from the perspective
of most signalling protocols,
gateways and MCUs are special
cases of endpoints.
enterprise directory:
A canonical collection of information
about users in an organization.
Typically this information is
collected from a variety of organizational
units to create a whole. For example,
Human Resources may provide name
and address, Telecommunications
may provide the telephone number,
Information Technology may provide
the email address, etc. For the
purposes of this architecture,
it is assumed that an enterprise
directory is accessible via LDAP.
White Pages:
An application that allows end
users to look up the address of
another user.
4 Abbreviations
LDAP: Lightweight
Directory Access Protocol as defined
in RFC 1777.
5 Conventions
In this Recommendation, the following
conventions are used:
"Shall" indicates a
mandatory requirement.
"Should" indicates a
suggested but optional course
of action.
"May" indicates an optional
course of action rather than a
recommendation that something
take place.
References to clauses, subclauses,
annexes and appendices refer to
those items within this Recommendation
unless another specification is
explicitly listed.
6 Object Class Definitions
The XmppIdentityURIObject represents
an XMPP URI; that is, the address
of an entity that is capable of
communicating using the XMPP protocol.
Because it is its own unique object
class, the directory can be searched
for the presence of this attribute.
Note that XMPP uses SASL for authentication,
enabling each deployment to make
use of its own authentication
mechanism. Because of this, there
are no authentication attributes
directly associated with the H.350.7
representation of XMPP. The URI
itself is sufficient to hook into
the entire application.
6.1
XmppURIObject Object Class
OID: 0.0.8.350.1.1.9.2.1
objectclasses: (0.0.8.350.1.1.9.2.1
NAME 'XmppURIObject'
DESC 'XmppURI object'
SUP top AUXILIARY
MAY ( XmppIdentityURI )
)
6.2
XmppIdentityURI attribute
OID: 0.0.8.350.1.1.9.1.1
attributetypes: (0.0.8.350.1.1.9.1.1
NAME 'XmppIdentityURI'
DESC 'Labeled URI format to represent
an XMPP URI'
EQUALITY caseExactMatch
EQUALITY caseExactSubstringsMatch
SYNTAX 1 1.3.6.1.4.1.1466.115.121.1.15)
Application utility class
standard
Number of values
multi
Definition
Specifies
an XMPP URI.
Permissible values (if controlled)
Notes
Semantics
Example applications for which
this attribute would be useful
Example (LDIF fragment)
7 XmppURIObject LDIF Files
This section contains a schema
configuration file for XmppURIObject
that can be used to configure
an LDAP server to support this
class.
#
XmppURIObject Object Schema
#
# Schema for representing a XmppURIObject
Object in an LDAP Directory
#
# Abstract
#
# This document defines the schema
for representing XmppURIObject
# object in an LDAP directory.
It defines schema elements
# to represent an XmppURIObject
object.
#
# .1 = Communication related work
# .1.9 = XmppURIObject
# .1.9.1 = attributes
# .1.9.2 = objectclass
# .1.9.3 = syntax
#
#
#
# Attribute Type Definitions
#
# The following attribute types
are defined in this document:
#
# XmppIdentityURI
dn: cn=schema
changetype: modify
#
# if you need to change the definition
of an attribute,
# then first delete and re-add
in one step
#
# if this is the first time you
are adding the genericIdentity
# objectclass using this LDIF
file, then you should comment
# out the delete attributetypes
modification since this will
# fail. Alternatively, if your
ldapmodify has a switch to continue
# on errors, then just use that
switch -- if you're careful
#
delete: attributetypes
attributetypes:(0.0.8.350.1.1.9.1.1
NAME 'XmppIdentityURI' )
-
#
# re-add the attributes -- in
case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.9.1.1
NAME
'XmppIdentityURI'
DESC
'Labeled URI format to represent
an XMPP URI'
EQUALITY
caseExactMatch
EQUALITY
caseExactSubstringsMatch
SYNTAX
1.3.6.1.4.1.1466.115.121.1.15
)
-
# Object Class Definitions
#
# The following object class is
defined in this document:
#
# XmppURIObject
#
# XmppURIObject
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.9.2.1
NAME 'XmppURIObject' )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.9.2.1
NAME
'XmppURIObject'
DESC
'XmppURI object'
SUP
top AUXILIARY
MAY
( XmppIdentityURI )
)
-
#
# end of LDIF
#
8 ASN.1 Representation
H.350.7 elements may be used in
an X.500 directory architecture
by using the ASN.1 representation
of the object classes defined
here.
XmppURIObject
{ itu-t(0) recommendation(0) h(8)
350 1 cr(1) xmpp(9) module(4)
}
DEFINITIONS ::=
BEGIN
-- XmppURIObject Object Schema
--
Schema for representing a XmppURIObject
Object in an LDAP Directory
-- Abstract
-- This document defines the schema
for representing XmppURIObject
-- object in an LDAP directory.
It defines schema elements
-- to represent an XmppURIObject
object.
--
.1
= Communication related work
--
.1.9
= XmppURIObject
--
.1.9.1
= attributes
--
.1.9.2
= objectclass
--
.1.9.3
= syntax
IMPORTS
-- from ITU-T Rec. H.350
h350-cr,
caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch
FROM CommURI { itu-t(0) recommendation(0)
h(8) 350 1 cr(1) commURI(1) module(4)
}
-- from ITU-T Rec. X.501 | ISO/IEC 9594-2
ATTRIBUTE,
OBJECT-CLASS, top
FROM
InformationFramework {joint-iso-itu-t
ds(5) module(1) informationFramework(1)
4}
-- from ITU-T Rec. X.520 | ISO/IEC 9594-6
DirectoryString
{}, caseExactMatch, caseExactSubstringsMatch
FROM
SelectedAttributeTypes {joint-iso-itu-t
ds(5) module(1) selectedAttributeTypes(5)
4} ;
--
Attribute Type Definitions
--
The following attribute types
are defined in this document:
-- XmppIdentityURI
XmppIdentityURI
ATTRIBUTE ::= {
WITH
SYNTAX DirectoryString {256}
EQUALITY
MATCHING RULE caseExactMatch
SUBSTRINGS
MATCHING RULE caseExactSubstringsMatch
ID
{ at 1 } }
--
Object Class Definitions
-- The following object class
is defined in this document:
--
--
XmppURIObject
-- XmppURIObject
XmppURIObject
OBJECT-CLASS ::= {
SUBCLASS
OF { top }
MAY
CONTAIN { XmppIdentityURI }
ID
{ oc 1 } }
call-Id
OBJECT
IDENTIFIER ::= { h350-cr call-Id(9)
}
at
OBJECT IDENTIFIER ::= { call-Id
at(1) }
oc
OBJECT IDENTIFIER ::= { call-Id
oc(2) }
END -- end of ASN.1
9 DSML Representation
H.350.7 elements may be described
using the Directory Services Markup
Language. That description is
as follows.
<dsml:dsml
xmlns:dsml='http://www.dsml.org/DSML'>
<dsml:directory-schema>
<dsml:attribute-type user-modification='false'
id='#XmppIdentityURI'>
<dsml:name>XmppIdentityURI</dsml:name>
<dsml:description>Labeled
URI format to represent an XMPP
URI</dsml:description>
<dsml:object-identifier>0.0.8.350.1.1.9.1.1</dsml:object-identifier>
<dsml:equality>caseExactMatch</dsml:equality>
<dsml:substr>caseExactSubstringsMatch</dsml:substr>
<dsml:syntax>1.3.6.1.4.1.1466.115.121.1.15</dsml:syntax>
</dsml:attribute-type>
<dsml:class
id='#XmppURIObject' superior='#top'
type='auxiliary'>
<dsml:name>XmppURIObject</dsml:name>
<dsml:description>XmppURI
object</dsml:description>
<dsml:object-identifier>0.0.8.350.1.1.9.2.1</dsml:object-identifier>
<dsml:attribute required='false'
ref='XmppIdentityURI' />
</dsml:class>
</dsml:directory-schema>
</dmsl:dmsl>
Annex A: Indexing Profile
A
Annex
A Indexing Profile
Indexing of attributes is an implementation-specific
activity and depends upon the
desired application. Non-indexed
attributes can result in search
times sufficiently long to render
some applications unusable. The
Annex A Indexing Profile describes
an indexing configuration for
XmppIdentityURI attributes that
will be optimized for efficient
call server lookup. Use of this
profile is optional.
XmppIdentityURI: equality
Appendix I Electronic Attachments
I Electronic Attachment
This section will contain electronic
versions of LDIF, ASN.1 and DSML
definitions in the final document.