RFC 3944

H.350 Directory Services

📅 published December 2004, from ietf

RFC 3944: H.350 Directory Services 🎀

okay bestie, let's get into it 💖 this one's an Informational RFC from the Network Working Group, dated December 2004. three co-authors wrote it:

  • T. Johnson (U. of North Carolina)
  • S. Okubo (Waseda University)
  • S. Campos (ITU-T)

the title block doesn't list anything it obsoletes or updates, so there's nothing to chase down there 🧚

Status of this Memo

this memo is just here to give the Internet community some info 📚 it's not a standard of any kind, and you're totally free to distribute it wherever you want 💅

Copyright (C) The Internet Society (2004).

Abstract

so the ITU-T (the International Telecommunications Union Standardization Sector) made the H.350 series of Recommendations 🌸 these lay out directory services architectures for multimedia conferencing protocols. the big idea is to "directory enable" conferencing, so it can plug into identity management systems and enterprise directories that already exist ✨

the dream goal is letting an enterprise or service provider keep one canonical source of its users and their conferencing systems. that way, call servers from different vendors, running different protocols, can all read from the same data store. iconic, honestly 👑

since SIP is an IETF standard, this doc brings the contents of H.350 and H.350.4 over to the IETF crowd 🦋 it holds the entire normative text of ITU-T Recommendations H.350 and H.350.4, in sections 4 and 5 respectively. everything else in here is only in this document, not in the ITU-T version 🫶

Table of Contents

1.   Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.   Conventions used in this document . . . . . . . . . . . . . .  4
4.   H.350 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . .  4
           4.1.1. Design Goals . . . . . . . . . . . . . . . . . .  6
           4.1.2. Extending the Schema . . . . . . . . . . . . . .  7
     4.2.  commURIObject Definition. . . . . . . . . . . . . . . . 10
           4.2.1. commURIObject. . . . . . . . . . . . . . . . . . 10
           4.2.2. commURI. . . . . . . . . . . . . . . . . . . . . 10
     4.3.  CommObject Definition . . . . . . . . . . . . . . . . . 11
           4.3.1. commObject . . . . . . . . . . . . . . . . . . . 11
           4.3.2. commUniqueId . . . . . . . . . . . . . . . . . . 11
           4.3.3. commOwner. . . . . . . . . . . . . . . . . . . . 12
           4.3.4. commPrivate. . . . . . . . . . . . . . . . . . . 13
     4.4.  CommObject LDIF Files . . . . . . . . . . . . . . . . . 13
           4.4.1. LDIF for commURIObject . . . . . . . . . . . . . 13
           4.4.2. LDIF for commObject. . . . . . . . . . . . . . . 15
     4.5.  H.350 Annex A Indexing Profile. . . . . . . . . . . . . 17
5.   H.350.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . 17
           5.1.1. Extending the schema . . . . . . . . . . . . . . 18
     5.2.  Object class definitions. . . . . . . . . . . . . . . . 18
           5.2.1. SIPIdentity. . . . . . . . . . . . . . . . . . . 18
           5.2.2. SIPIdentitySIPURI. . . . . . . . . . . . . . . . 19
           5.2.3. SIPIdentityRegistrarAddress. . . . . . . . . . . 19
           5.2.4. SIPIdentityProxyAddress. . . . . . . . . . . . . 20
           5.2.5. SIPIdentityAddress . . . . . . . . . . . . . . . 21
           5.2.6. SIPIdentityPassword. . . . . . . . . . . . . . . 21
           5.2.7. SIPIdentityUserName. . . . . . . . . . . . . . . 22
           5.2.8. SIPIdentityServiceLevel. . . . . . . . . . . . . 23
     5.3.  SIPIdentity LDIF Files. . . . . . . . . . . . . . . . . 23
     5.4.  H.350.4 Annex A Indexing profile. . . . . . . . . . . . 26
6.   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7.   Security Considerations . . . . . . . . . . . . . . . . . . . 27
8.   References. . . . . . . . . . . . . . . . . . . . . . . . . . 28
     8.1.  Normative References. . . . . . . . . . . . . . . . . . 28
     8.2.  Informative References. . . . . . . . . . . . . . . . . 28
9.   Relationship to Other Specifications. . . . . . . . . . . . . 29
10.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 29
     Full Copyright Statement. . . . . . . . . . . . . . . . . . . 30

1. Scope 🌈

the ITU-T is behind the H.350 series, and it's all about directory services for multimedia conferencing 🎀 the whole point is to "directory enable" conferencing so it can reuse the identity and enterprise directories you already have. the vibe is: one source of truth for users and their conferencing setups, shared across call servers from different vendors that speak different protocols 💜

H.350 isn't here to mess with how conferencing protocols work 🙅‍♀️ it's just about storing the protocol elements that already exist in a directory, in a standardized way, so anyone can access them the same way 🧚

inside the H.350 series, Recommendation H.350 covers the base architecture and object classes, and the subordinate Recommendations cover the stuff specific to each protocol. here's the current lineup:

H.350   - Directory Services Architecture for Multimedia Conferencing
H.350.1 - Directory Services Architecture for H.323
H.350.2 - Directory Services Architecture for H.235
H.350.3 - Directory Services Architecture for H.320
H.350.4 - Directory Services Architecture for SIP
H.350.5 - Directory Services Architecture for Non-Standard Protocols

and since SIP is an IETF standard, H.350 and H.350.4 get shared with the IETF through this document 🦋

2. Terminology ✨

these are the terms the document uses all the way through 📝

  • 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 💅
  • endpoint: a logical device that provides video and/or voice media encoding/decoding, and signalling functions. examples include:
    • a group teleconferencing appliance that is located in a conference room
    • an IP telephone
    • a software program that takes video and voice from a camera and microphone and encodes it and applies signalling using a host computer
  • enterprise directory: a canonical collection of information about users in an organization. this info is usually gathered from a bunch of organizational units to make a whole picture. 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's assumed that an enterprise directory is accessible via LDAP 🫶
  • White Pages: an application that lets end users look up the address of another user. this may be web-based or use some other user interface 🍓

3. Conventions used in this document 💜

the conventions here follow ITU-T guidelines 📐 in this Recommendation, these are the conventions in play:

"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, sub clauses, annexes and appendices point to those items within this Recommendation, unless another specification is explicitly listed. so you always know where you're looking 👑

4. H.350 🦋

the normative text of H.350 gets reproduced right here in this section 🌸

ok that's part 1 of 6 bestie 💖 part 2 is coming up next, so stay tuned 🫶

4.1. Scope 🎀

okay so this Recommendation is all about a directory services architecture for multimedia conferencing, and it runs on LDAP 🧚 standardized directory services can connect people to their endpoints, power searchable white pages, and make clickable dialling possible 📞 they can also help configure endpoints and handle user authentication based on authoritative data sources 🔐 this doc describes a standardized LDAP schema for representing endpoints on the network and linking those endpoints to users. It also talks through design and implementation considerations for how video and voice directories, enterprise directories, call servers and endpoints relate to each other 💖

The use of one common, authoritative data source for call server, endpoint, user, authentication and white pages information is a big deal in large-scale multimedia conferencing environments 😭 without a shared data source, service providers have to build separate processes to manage each of these functions, which is so much extra work. When the LDAP schema used to represent the underlying data is standardized, products from different system vendors can be deployed together to build one overall application environment ✨ for example, a white pages search engine from one provider could serve directory information to IP telephones made by a second provider, while signalling is handled by a call server from a third provider 🫶 each of these disparate systems can access the same underlying data source, which reduces or even removes the need to coordinate separate management of each system. The benefit for users is huge too: the management of this data can be folded into existing customer management tools, which allows quick and flexible scaling up of applications 🚀 honestly, many technology providers have already incorporated LDAP into their products, but they've been forced to do it without a standardized schema to lean on 💀 this Recommendation is an effort to standardize those representations so interoperability and performance get better 🌈

While URLs are already standardized for several conferencing protocols, their representation in a directory is not 🙈 this Recommendation supports a standardized way for URLs to be searched for and located, which is a necessary step to support 'clickable dialling' 📞

Managing endpoint configurations gets so much better when the correct settings are stored by the service provider in a location that both the service provider and the endpoint can reach 🧁 LDAP gives you a convenient storage location that both call server and endpoint can access, so the directory can be used to support endpoint configuration. That matters for simplified operation and for supporting user mobility 🦋 note that other technologies also handle endpoint configuration, notably SNMP for complete configuration and SRV records for obtaining registration server addresses. So H.350 should be seen not as the authoritative endpoint configuration architecture, but as one tool that can help with this task 🍓 also, the use of H.350 has endpoint-specific configuration as a feature, meaning it's desirable that each endpoint has a unique configuration 💜

This architecture uses a generic object class, called commObject, to represent attributes that are common to any video or voice protocol 👑 auxiliary classes represent specific protocols, such as H.323, H.235, or H.320, as described in the H.350.x series of Recommendations. Multiple H.350.x classes can be combined to represent endpoints that support more than one protocol. For example, endpoints that support H.323, H.235 and H.320 would include H.350, H.350.1, H.350.2, and H.350.3 in their LDAP representations 🌸 further, each entry should contain commObject to serve as the entry's structural object class ✨

There are two basic components in the architecture 🦋 the commURI object is a class whose only purpose is to link a person or resource to a commObject. By placing a commURI 'pointer' in an individual's directory entry, that individual becomes associated with the particular targeted commObject 💅 similarly, commObject contains a pointer, called commOwner, which points to the individual or resource associated with the commObject. That's how people or resources get associated with endpoints, and it's giving main character energy 👑 the only change required in the enterprise directory is the addition of the simple object class commURI. CommObject data may be instantiated in the same directory or in entirely separate directories, which allows flexibility in implementation 🧚

4.1.1. Design Goals 💖

large-scale deployments of IP video and voice services have shown the need for complementary directory services middleware 🔥 service administrators need call servers that are aware of enterprise directories, so they don't end up duplicating account management processes. Users need 'white pages' to find other users they want to communicate with 🫶 all of these processes should pull their information from canonical data sources, which reduces redundant administrative processes and keeps information accurate. The following design criteria are established for this architecture. The architecture will:

  1. enable endpoint information to be associated with people. Alternately, it enables endpoint information to be associated with resources such as conference rooms or classrooms 🏫
  2. enable online searchable "white pages" where dialling information (e.g., endpoint addresses) can be found, along with other "traditional" directory information about a user, such as name, address, telephone, email, etc. 📇
  3. enable all endpoint information to be stored in a canonical data source (the Directory), rather than local to the call server, so that endpoints can be managed through manipulations of an enterprise directory, rather than by direct entry into the call server 🗂️
  4. support the creation of very large-scale distributed directories. These include white pages "portals" that allow searching for users across multiple institutional directories. In this application, each enterprise directory registers itself with (or is unknowingly discovered by) a directory of directories that is capable of searching across multiple LDAP directories 🌍
  5. be able to support multiple instances of endpoints per user or resource 🌈
  6. represent endpoints that support more than one protocol, for example, endpoints that are both H.320 and H.323 🎀
  7. store enough information about endpoint configuration so that correct configuration settings can be documented to end users on a per-endpoint basis, as a support tool, or loaded automatically into the endpoint 🛠️
  8. be extendible as necessary to allow implementation-specific attributes to be included 🧩
  9. be non-invasive to the enterprise directory, so that support for multimedia conferencing can be added in a modular fashion without significant changes to the enterprise directory 🦋

The scope of this Recommendation does not include extending functionality of protocols as defined within the protocols themselves 🙅‍♀️ it's not the intent of the Recommendation to add features, only to represent existing protocol attributes. The exception is when functionality is implied by the directory itself, such as the commPrivate attribute 💜

4.1.2. Extending the Schema ✨

H.350 object classes may be extended as necessary for specific implementations. For example, a class may be extended to support billing reference codes 💸 extensions to the schema are not considered part of the Recommendation and do not signify compliance.

In some cases it may be necessary to extend the H.350 schemas in order to represent more information than the Recommendations support 🤓 this may be important for developers who implement proprietary endpoint functionality that needs to be represented by attributes in the directory. It may also be important for enterprise applications. For example, 'modelNumber' and 'accountNumber' are attributes that are not defined in the Recommendation but may be useful if implemented 🔢 adding attributes to this architecture must be done in a way that does not break compatibility with this Recommendation.

A full discussion of schema design and extension is beyond the scope of this Recommendation. See IETF RFC 2252 for details. Two basic approaches to schema extension that do not break compatibility with this Recommendation are extension through subclass and extension through the use of auxiliary classes 🧁

4.1.2.1. Extension Through Subclass 🍒

It's possible to create a subclass of an existing predefined object class in order to add new attributes to it 🌷 to create a subclass, a new object class must be defined that is a subclass of the existing one, by indicating in the definition of the new class that the existing class is its superior. Once the subclass is created, new attributes can be defined within it 🎀

The following example shows how the commObject class can be subclassed to add an attribute that represents a billing account and a billing manager 💅

objectclass ( BillingInfo-OID
NAME 'BillingInfo'
DESC 'Billing Reference Information'
SUP commObject STRUCTURAL
MAY ( BillingAccount $ BillingManager $ )
)

Note that BillingInfo-OID must be replaced by an actual OID 🙏 also note that, whenever a structural class is extended, its subclass must also be structural 🔥

The following sample entry shows the newly created attributes. This example also uses ITU-T Rec. H.350.1 for h323Identity 🧚

dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: h323Identity
objectclass: BillingInfo
commUniqueId: 2000
BillingAccount: 0023456
BillingManager: John Smith

Note that this example and approach demonstrate extension of the general commObject object class, and not any individual H.350.x classes. If it is desired to extend an H.350.x auxiliary class, then that should be accomplished through the definition of additional auxiliary classes that support the desired attributes, as described in section 4.1.2.2 🌈✨

4.1.2.2. Extension Through The Use Of Auxiliary Classes

okay so the other way to add attributes is an auxiliary class 🎀 you make a class that holds your new attributes, then slap it onto entries that already exist in the directory. it's giving modular. the auxiliary class does NOT get subclassed from any existing object class, and it should have the special class top as its superior ✨

the example below makes the same billing account and billing manager attributes as the last one, except this time they live in their own auxiliary class 💅

objectclass ( BillingInfo-OID
NAME 'BillingInfo'
DESC 'Billing Reference Information'
SUP top AUXILIARY
MAY ( BillingAccount $ BillingManager $ )
)

notice the superior changed from commObject to top, and the object class changed from structural to auxiliary 👀 that's the whole glow-up 🦋

it's recommended that every attribute in the auxiliary class is optional instead of mandatory 🫶 that way the auxiliary object class can be attached to an entry whether or not any of its attribute values are actually there 🌸

here's a sample endpoint using the new auxiliary class and attributes. this one also uses H.350.1 for h323Identity 💜

dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: BillingInfo
commUniqueId: 2000
BillingAccount: 0023456
BillingManager: John Smith

4.1.2.3. Object Identifiers

an attribute's Object Identifier (OID) is a unique numerical ID, usually written as a bunch of integers separated by dots 🔢 for example, the OID for commUniqueId is 0.0.8.350.1.1.2.1.1. every attribute has to have an OID ✨ you can get OIDs from anyone who already has one and is willing to delegate a piece of it as an arc, as long as they keep a record of that arc so nobody doubles up 🧚 and the Internet Assigned Numbers Authority (IANA) hands OIDs out to any organization that asks 🌈

4.2. commURIObject Definition

this is an auxiliary object class that holds the commURI attribute 🦋 you bolt it onto a person or resource object to link it to one or more commObject instances. the values are LDAP URIs pointing at those commObjects, like a user's H.323 conferencing station and SIP IP phone 📞 heads up: multiple commURI instances don't have to point at the same commObject directory 👀 each one could point at an endpoint run by a totally different service provider 🌍

4.2.1. commURIObject

OID: 0.0.8.350.1.1.1.2.1

objectclasses: (0.0.8.350.1.1.1.2.1
NAME 'commURIObject'
DESC 'object that contains the URI attribute type'
SUP top AUXILIARY
MAY ( commURI )
)

4.2.2. commURI

OID: 0.0.8.350.1.1.1.1.1

attributetypes:( 0.0.8.350.1.1.1.1.1
NAME 'commURI'
DESC 'Labeled URI format to point to the distinguished name of the
commUniqueId'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Application utility class: Standard Number of values: multi Definition: it's a labelled URI containing an LDAP URL that identifies the directory holding the referenced commObject instance 🗂️ the search filter inside that LDAP URL shall specify an equality search of the commUniqueId attribute of the commObject class 🔍 Permissible values (if controlled): (nothing listed) Notes: this is how you find a user's endpoint 🕵️‍♀️ the label part can describe what the endpoint does, like 'home IP phone' or 'desktop video', for showing in a user interface 💅 the label is allowed to have spaces, like 'desktop video' in the example below ✨ Semantics: (nothing listed) Example applications for which this attribute would be useful: (nothing listed) Example (LDIF fragment):

commURI:
ldap://directory.acme.com/dc=acme,dc=com??sub?(commUniqueId=bob)
desktop video

4.3. CommObject Definition

this one is an abstraction of a video or voice over IP device 📹 the commObject class lets an endpoint (an H.323 endpoint, a SIP user agent, or some other protocol endpoint) and all of its aliases be represented by one single directory entry 🎀 every directory entry should have commObject as its structural object class, and that entry can also carry H.350.x auxiliary classes 💜

4.3.1. commObject

OID: 0.0.8.350.1.1.2.2.1

objectclasses: (0.0.8.350.1.1.2.2.1
NAME 'commObject'
DESC 'object that contains the Communication attributes'
SUP top STRUCTURAL
MUST commUniqueId
MAY ( commOwner $ commPrivate )
)

4.3.2. commUniqueId

OID: 0.0.8.350.1.1.2.1.1

attributetypes: (0.0.8.350.1.1.2.1.1
NAME 'commUniqueId'
DESC 'To hold the endpoints unique Id'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Application utility class: standard Number of values: multi Definition: the endpoint's unique ID 🆔 Permissible values (if controlled): (nothing listed) Notes: this is the RDN of the object 🌟 in practice there's always one and only one commUniqueId per endpoint 💖 it uniquely identifies an endpoint inside the commObject directory. it must be unique within that directory, but it doesn't have to be unique globally 🌍 and it has zero relationship to the enterprise directory, so don't mix them up 🙅‍♀️ Semantics: (nothing listed) Example applications for which this attribute would be useful: (nothing listed) Example (LDIF fragment):

commUniqueId: bob

4.3.3. commOwner

OID: 0.0.8.350.1.1.2.1.2

attributetypes: 0.0.8.350.1.1.2.1.2
NAME 'commOwner'
DESC 'Labeled URI to point back to the original owner'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Application utility class: Standard Number of values: multi Definition: a labelled URI format that points back to the person or resource object associated with this entry 🔙 Permissible values (if controlled): (nothing listed) Notes: this is used as a reverse entry finder for the owner(s) 🔎 this attribute may point to groups. note that the URI can point to a cn, but if you want to bind authentication info across both the commObject and enterprise directories, it may be better for commOwner to point to a dn instead of a cn, since that uniquely identifies the owner of the commObject 🫶 Semantics: (nothing listed) Example applications for which this attribute would be useful: (nothing listed) Example (LDIF fragment):

commOwner:
ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith)
commOwner: uid=bob,ou=people,dc=acme,dc=com

4.3.4. commPrivate

OID: 0.0.8.350.1.1.2.1.3

attributetypes: (0.0.8.350.1.1.2.1.3
NAME 'commPrivate'
DESC 'To decide whether the entry is visible to world or not'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Application utility class: Standard Number of values: multi Definition: the user sets this to indicate privacy options for an endpoint, like an unlisted number 🤫 Permissible values (if controlled): (nothing listed) Notes: this attribute is defined as Boolean 🔐 a future version of this Recommendation may develop a controlled vocabulary for it, so it can handle several different kinds of privacy 🌸 Semantics: (nothing listed) Example applications for which this attribute would be useful: (nothing listed) Example (LDIF fragment):

commPrivate: true

4.4. CommObject LDIF Files

this section has a schema configuration file for commURIObject and commObject 🍓 you can use it to set up an LDAP server so it supports these classes 🧚

4.4.1. LDIF for commURIObject

# Communication Object Schema
#
# Schema for Representing Communication Objects in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing Communication
# objects in an LDAP directory [LDAPv3].  It defines schema elements
# to represent a communication object URI [commURIObject].
#
#
#
#                     .1 = Communication related work
#                     .1.1 = commURIObject
#                     .1.1.1 = attributes
#                     .1.1.2 = objectclass
#                     .1.1.3 = syntax
#
# Attribute Type Definitions
#
#    The following attribute types are defined in this document:
#
#        commURI
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 commObject
# 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.1.1.1 NAME 'commURI' )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.1.1.1
     NAME 'commURI'
     DESC 'Labeled URI format to point to the distinguished name of
the commUniqueId'
     EQUALITY caseExactMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
# Object Class Definitions
#
#    The following object classes are defined in this document:
#
#        commURIObject
#
# commURIObject
#
#    This auxiliary object class represents a URI attribute type
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.1.2.1
     NAME 'commURIObject'
     DESC 'object that contains the URI attribute type'
     SUP top AUXILIARY
     MAY ( commURI )
        )
-
#
# end of LDIF
#

4.4.2. LDIF for commObject

# Communication Object Schema
#
# Schema for Representing Communication Objects in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing Communication
# objects in an LDAP directory [LDAPv3].  It defines schema elements
# to represent a communication object [commObject].
#
#
#                     .1 = Communication related work
#                     .1.2 = commObject
#                     .1.2.1 = attributes
#                     .1.2.2 = objectclass
#                     .1.2.3 = syntax
#
#
# Attribute Type Definitions
#
#    The following attribute types are defined in this document:
#
#        commUniqueId
#        commOwner
#        commPrivate
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 commObject
# 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.2.1.1 NAME 'commUniqueId' )
attributetypes: (0.0.8.350.1.1.2.1.2 NAME 'commOwner' )
attributetypes: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.2.1.1
     NAME 'commUniqueId'
     DESC 'To hold the endpoints unique Id'
     EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.2.1.2
     NAME 'commOwner'
     DESC 'Labeled URI to point back to the original owner'
     EQUALITY caseExactMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.2.1.3
     NAME 'commPrivate'
     DESC 'To decide whether the entry is visible to world or not'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
# Object Class Definitions
#
#    The following object classes are defined in this document:
#
#        commObject
#
# commObject
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.2.2.1
     NAME 'commObject'
     DESC 'object that contains the Communication attributes'
     SUP top STRUCTURAL
     MUST commUniqueId
     MAY ( commOwner $ commPrivate )
     )
-
#
# end of LDIF
#

4.5. H.350 Annex A Indexing Profile 🧚

Okay so indexing is totally an implementation-specific thing and it depends on what your app is doing 🤓. If attributes aren't indexed, searches can take so long that some apps become basically unusable 💀. User and alias lookup especially needs to be fast, bestie.

The Annex A Indexing Profile describes an indexing setup for commObject directories that's tuned for directory of directories apps. Using this profile is optional.

  • commURI: no recommendation
  • commUniqueId: equality
  • commOwner: presence
  • commPrivate: presence

5. H.350.4 🎀

This section is where the normative text of H.350 gets reproduced, so you get the full official vibe ✨.

5.1. Scope 💅

Okay so this Recommendation lays out an LDAP directory services architecture for multimedia conferencing using SIP. Specifically, it defines an LDAP schema that represents SIP User Agents (UAs) on the network and links those endpoints back to users.

This Recommendation is meant to supplement the CommObject directory architecture discussed in ITU-T Rec. H.350, and it is not meant to be used as a stand-alone architecture. Implementing this LDAP schema together with the H.350 CommObject architecture helps you plug SIP User Agents and conferencing devices into existing Enterprise Directories 📇. That means users can do white page lookups and access clickable dialling supported by SIP devices. The main reasons for doing this are the ones listed in ITU-T Rec. H.350 (the CommObject class definition) as they apply specifically to SIP UAs, plus helping vendors make SIP services easier for their users to get. 🫶

The scope of this Recommendation includes recommendations for the architecture that brings endpoint information for SIP endpoints into existing enterprise directories and white pages.

The scope of this Recommendation does not include normative methods for using the LDAP directory itself or the data it contains. The schema isn't trying to represent every possible data element in SIP. It only represents the minimal set needed to hit the design goals listed in ITU-T Rec. H.350 🎯.

Note that SIP has well-defined methods for discovering registrar addresses and locating users on the network 🌐. Some of the attributes here are meant for simpler or manual setups and may not be needed for every app. For example, SIPIdentityRegistrarAddress and SIPIdentityAddress may not be needed for lots of apps, but they're included for completeness. So SIPIdentitySIPURI is the main attribute of interest that gets served out, especially for white page directory apps 🦋.

5.1.1. Extending the schema 🌸

The SIPIdentity classes can be extended as needed for specific implementations. Check the base of ITU-T Rec. H.350 for a discussion on schema extension.

5.2. Object class definitions 👑

The SIPIdentity object class represents SIP User Agents (UAs). It's an auxiliary class, and it's derived from the commObject class, which is defined in ITU-T Rec. H.350. ✨

5.2.1. SIPIdentity 💖

OID: 0.0.8.350.1.1.6.2.1

objectclasses: (0.0.8.350.1.1.6.2.1
NAME 'SIPIdentity'
DESC 'SIPIdentity object'
SUP top AUXILIARY
MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $
   SIPIdentityProxyAddress $ SIPIdentityUserName $
   SIPIdentityPassword $ SIPIdentityServiceLevel $
   userSMIMECertificate )
)

5.2.2. SIPIdentitySIPURI 🦋

OID: 0.0.8.350.1.1.6.1.1

attributetypes: (0.0.8.350.1.1.6.1.1
NAME 'SIPIdentitySIPURI'
DESC 'Universal Resource Indicator of the SIP UA'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Application utility class: standard Number of values: multi Definition: A Uniform Resource Identifier that identifies a communication resource in SIP 💅. It usually has a user name and a host name, and it's often kinda like an email address. Permissible values (if controlled): left blank in the spec. Notes: This URI may use SIP or SIPS (the secure one). If SIPS is in use, the URI must show that it's SIPS and not plain SIP. Check the examples below 👀. Semantics: left blank in the spec. Example applications for which this attribute would be useful: an online representation of a user's most current listing of their SIP(S) UA 📋.

Example:

SIPIdentitySIPURI: sip:alice@foo.com          // SIP example
SIPIdentitySIPURI: sip:alice@152.2.158.212    // SIP example
SIPIdentitySIPURI: sips:bob@birmingham.edu    // SIPS example

5.2.3. SIPIdentityRegistrarAddress 🎀

OID: 0.0.8.350.1.1.6.1.2

attributetypes: (0.0.8.350.1.1.6.1.2
NAME 'SIPIdentityRegistrarAddress'
DESC 'specifies the location of the registrar'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Application utility class: Standard Number of values: multi Definition: The address for the domain that the server handling REGISTER requests belongs to, along with forwarding to the location server for a particular domain. Permissible values (if controlled): left blank in the spec. Notes: Okay so RFC 3261 says user agents can discover their registrar address by configuration, using the address-of-record, or by multicast 🤔. The first one, configuration, is marked as out of scope for RFC 3261. This attribute can be used for that first scenario. You can set it up manually (like a web page that shows a user's correct registrar address) or automatically with an H.350.4 aware user agent ⚙️. Semantics: left blank in the spec. Example applications for which this attribute would be useful: white pages, or a web page that displays a user's correct configuration information 💻.

Example (LDIF fragment):

SIPIdentityRegistrarAddress: 152.2.15.22     //IP address example
SIPIdentityRegistrarAddress: sipregistrar.unc.edu  //FQDN example

5.2.4. SIPIdentityProxyAddress 🧚

OID: 0.0.8.350.1.1.6.1.3

attributetypes: (0.0.8.350.1.1.6.1.3
NAME 'SIPIdentityProxyAddress'
DESC 'Specifies the location of the SIP Proxy'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Application utility class: Standard Number of values: multi Definition: The address that gives the domain location of a SIP proxy within a domain. RFC 3261 defines the role of the SIP proxy 🔁. Permissible values (if controlled): left blank in the spec. Notes: SIP User Agents are not REQUIRED to use a proxy, but in lots of cases they will 🙃. Semantics: left blank in the spec. Example applications for which this attribute would be useful: white pages, or a web page that displays a user's correct configuration information.

Example (LDIF fragment):

SIPIdentityProxyAddress: 172.2.13.234     //IP address example
SIPIdentityProxyAddress: sipproxy.unc.edu  //FQDN example

5.2.5. SIPIdentityAddress 🌷

OID: 0.0.8.350.1.1.6.1.4

attributetypes: (0.0.8.350.1.1.6.1.4
NAME 'SIPIdentityAddress'
DESC 'IP address or FQDN of the UA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Application utility class: standard Number of values: multi Definition: Specifies the IP address or fully qualified domain name of the UA. Permissible values (if controlled): left blank in the spec. Notes: This attribute may be useful for apps where UA to UA communication is direct, with no proxy or registrar in the middle 🤝. Example applications for which this attribute would be useful: a web page that displays a user's proper user agent configuration information.

Example (LDIF fragment):

SIPIdentityAddress: 152.2.121.36       // IP address example
SIPIdentityAddress: ipPhone.foo.org    // FQDN example

5.2.6. SIPIdentityPassword 🔐

OID: 0.0.8.350.1.1.6.1.5

attributetypes: (0.0.8.350.1.1.6.1.5
NAME 'SIPIdentityPassword'
DESC 'The user agent SIP password '
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

Application utility class: Standard Number of values: multi Definition: The SIP user agent's password, used for the HTTP digest authentication scheme as defined in RFC 2617. Permissible values (if controlled): left blank in the spec. Notes:

  • Because RFC 2069 was made obsolete by RFC 2617, and it was used as the basis for HTTP Digest in RFC 2543, any SIP servers supporting RFC 2617 must ensure backward compatibility with RFC 2069 🕰️.
  • This SIPIdentityUserName, together with SIPIdentityPassword, is reserved for use with Digest Access Authentication, and it's not intended for use with Basic Authentication methods 🚫.
  • LDAP gives you one method to store user passwords for reference. If passwords are stored in LDAP, the LDAP server becomes a particularly valuable target for attack.
🚨 Implementors are encouraged to be really careful here and put appropriate security procedures in place, such as encryption, access control, and transport layer security for access to this attribute. Passwords in a directory are a big deal, bestie 😭.

Semantics: left blank in the spec. Example applications for which this attribute would be useful: left blank in the spec.

Example (LDIF fragment):

SIPIdentityPassword: 36zxJmCIB18dM0FVAj

5.2.7. SIPIdentityUserName 🌈

OID: 0.0.8.350.1.1.6.1.6

attributetypes: (0.0.8.350.1.1.6.1.6
NAME 'SIPIdentityUserName'
DESC 'The user agent user name.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Application utility class: Standard Number of values: multi Definition: The SIP user agent's user name, used for the HTTP digest authentication scheme as defined in RFC 2617. Permissible values (if controlled): left blank in the spec. Notes:

  • Because RFC 2069 was made obsolete by RFC 2617, and it was used as the basis for HTTP Digest Authentication in RFC 2543, any SIP servers supporting HTTP Digest Authentication as defined in RFC 2617 must ensure backward compatibility with RFC 2069 🧁.
  • This SIPIdentityUserName, together with SIPIdentityPassword, is reserved for use with Digest Access Authentication, and it's not intended for use with Basic Authentication methods 🚫.
  • Note that in many cases the user name will be parsed from the user@proxy.domain portion of the SIP URI. In that case, it may not be necessary to populate this attribute 🧠.

Semantics: left blank in the spec. Example applications for which this attribute would be useful: left blank in the spec.

Example (LDIF fragment):

SIPIdentityUserName: nelkhour

5.2.8. SIPIdentityServiceLevel ✨

Okay bestie, this one is about service levels 💅 The definition is a whole lot of "services a user can belong to" energy 🎀

   OID: 0.0.8.350.1.1.6.1.7
   attributetypes: (0.0.8.350.1.1.6.1.7
   NAME 'SIPIdentityServiceLevel'
   DESC 'To define services that a user can belong to.'
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
   Application utility class
        Standard
   Number of values
        multi
   Definition
        This describes the level of services a user can belong to.
   Permissible values (if controlled)
   Notes
        This attribute does not represent a data element found in SIP.
   SIP itself does not support distinctions in service levels.  Instead,
   this attribute provides a mechanism for the storage of service level
   information directly in LDAP.  This mapping allows service providers
   to adapt to an existing LDAP directory without changing the values
   of the SIPIdentityServiceLevel instances in the directory.
   Semantics
   Example applications for which this attribute would be useful
   Example (LDIF fragment)
   SIPIdentityServiceLevel: premium

Here's the tea 🫖 SIP itself has no concept of service level distinctions. So this attribute is basically a spot to stash service level info straight into LDAP 🧚 The best part is that service providers can plug into an existing LDAP directory without having to change the SIPIdentityServiceLevel values already sitting in there. Iconic behaviour, honestly 👑

5.3. SIPIdentity LDIF Files

This part has a schema configuration file for SIPIdentity 📄 You can use it to set up an LDAP server so it supports this class 🌸

# SIPIdentity Object Schema
#
# Schema for representing SIPIdentity Object in an LDAP Directory
#
# Abstract
#
# This Recommendation defines the schema for representing
SIPIdentity
# object in an LDAP directory [LDAPv3].  It defines schema elements
# to represent an SIPIdentity object [SIPIdentity].
#
#                     .1 = Communication related work
#                     .1.6 = SIPIdentity
#                     .1.6.1 = attributes
#                     .1.6.2 = objectclass
#                     .1.6.3 = syntax
#
#
#
# Attribute Type Definitions
#
#    The following attribute types are defined in this
Recommendation:
#
#     SIPIdentitySIPURI
#     SIPIdentityRegistrarAddress
#     SIPIdentityProxyAddress
#     SIPIdentityAddress
#     SIPIdentityPassword
#     SIPIdentityUserName
#     SIPIdentityServiceLevel
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 SIPIdentity
# 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 are careful
#
delete: attributetypes
attributetypes: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' )
attributetypes: (0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress')
attributetypes: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress')
attributetypes: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' )
attributetypes: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' )
attributetypes: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' )
attributetypes: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel')
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.6.1.1
     NAME 'SIPIdentitySIPURI'
     DESC 'Universal Resource Indicator of the SIP UA'
     EQUALITY caseExactMatch
     SUBSTR caseExactSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetypes: (0.0.8.350.1.1.6.1.2
     NAME 'SIPIdentityRegistrarAddress'
     DESC 'specifies the location of the registrar'
     EQUALITY caseIgnoreIA5Match
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.6.1.3
     NAME 'SIPIdentityProxyAddress'
     DESC 'Specifies the location of the SIP Proxy'
     EQUALITY caseIgnoreIA5Match
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.6.1.4
     NAME 'SIPIdentityAddress'
     DESC 'IP address of the UA'
     EQUALITY caseIgnoreIA5Match
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.6.1.5
     NAME 'SIPIdentityPassword'
     DESC 'The user agent SIP password '
     EQUALITY octetStringMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetypes: (0.0.8.350.1.1.6.1.6
     NAME 'SIPIdentityUserName'
     DESC 'The user agent user name.'
     EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.6.1.7
     NAME 'SIPIdentityServiceLevel'
     DESC 'To define services that a user can belong to.'
     EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
# Object Class Definitions
#
#    The following object class is defined in this Recommendation:
#
#        SIPIdentity
#
# SIPIdentity
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.6.2.1
     NAME 'SIPIdentity'
     DESC 'SIPIdentity object'
     SUP top AUXILIARY
     MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $
          SIPIdentityProxyAddress $ SIPIdentityAddress $
          SIPIdentityPassword $ SIPIdentityUserName $
          SIPIdentityServiceLevel $ userSMIMECertificate )
     )
-
#
# end of LDIF
#

5.4. H.350.4 Annex A Indexing profile 🔍

Indexing is an implementation-specific thing and it depends on what your app is doing 💖 If attributes aren't indexed, searches can get so slow that some applications become basically unusable 💀 User and alias lookup especially needs to be fast, so that's a big deal.

The Annex A Indexing Profile is the indexing setup for SIPIdentity directories that's tuned for directory-of-directories applications ✨ Using this profile is optional, so it's your call 🫶 Here's what it says:

  • SIPIdentitySIPURI: equality
  • SIPIdentityRegistrarAddress: no recommendation
  • SIPIdentityProxyAddress: no recommendation
  • SIPIdentityAddress: equality
  • SIPIdentityUserName: equality
  • SIPIdentityPassword: no recommendation
  • SIPIdentityServiceLevel: equality

6. Acknowledgments 🌈

We're so grateful to tons of colleagues who reached across standards bodies, research networks, academia, and private industry to build an architecture that brings multimedia conferencing deployments together 🦋 The standards from both IETF and ITU-T were used a LOT, and the architecture is meant to serve every community 💜

This work came out of the Video Conferencing Middleware (VidMid-VC) working group, a joint effort of Internet2 (www.internet2.edu) and the Video Development Initiative (www.vide.net) 🎀 The architecture was built in response to deployment challenges found in the ViDeNet (https//:videnet.unc.edu) academic test bed, which provides video and voice over IP infrastructure across research networks internationally 🌍

This work was supported in part by a grant from the United States National Science Foundation, contract number ANI-0222710 🙏

7. Security Considerations 🔐

Okay, this section is serious business 😭 It isn't in the ITU-T standard, but it gives info for the IETF community. Its content has the consensus of the ITU-T Study Group 16 ✨

H.350 doesn't change the security architecture of any particular protocol. What it does do is offer a standardized place to store authentication credentials where that makes sense 🧚 Worth noting: both H.323 and SIP support shared secret authentication (H.235 Annex D and HTTP Digest, respectively). These approaches require that the call server has access to the password. So if the call server or H.350 directory gets compromised, passwords may also become compromised 💀 These weaknesses may come from the systems themselves (the H.350 directory or call servers) and how they're run, rather than from H.350 per se.

The userSMIMECertificate attribute is defined in RFC 2798 (section 2.8) as part of inetOrgPerson. The SIP user agent's X.509 certificate can be stored in this attribute. When the certificate is present, it can be used with S/MIME to provide authentication, integrity, and confidentiality as specified in RFC 3261 [5] 🔑

It's strongly encouraged that call servers and an H.350 directory mutually authenticate each other before sharing information. Also, it's strongly encouraged that communications between H.350 directories and call servers or endpoints happen over secure communication channels such as SSL or TLS 🫶

Last but not least, access control lists on LDAP servers are a matter of policy and are not part of the standard. System administrators are advised to use common sense when setting access control on H.350 attributes 🙈

Main character warning: for example, password attributes should only be accessible by the authenticated user, while address attributes might be publicly available. Don't mix those up 🚨

8. References 📚

8.1. Normative References

  • [1] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
  • [2] ITU-T Recommendation H.350, "Directory services architecture for multimedia conferencing", 2003.
  • [3] ITU-T Recommendation H.350.4, "Directory services architecture for SIP", 2003.
  • [4] Franks, J., Hallam-Baker P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
  • [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
  • [7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.

8.2. Informative References

  • [8] ITU-T Recommendation H.350.1, "Directory services architecture for H.323", 2003.
  • [9] ITU-T Recommendation H.350.2, "Directory services architecture for H.235", 2003.
  • [10] ITU-T Recommendation H.350.3, "Directory services architecture for H.320", 2003.
  • [11] ITU-T Recommendation H.350.5, "Directory services architecture for Non-Standard Protocols", 2003.
  • [12] ITU-T Recommendation H.350.6, "Directory services architecture for Call Forwarding and Preferences", 2004.
  • [13] Howes T. and M. Smith, "Understanding And Deploying LDAP Directory Services", New Riders Publishing, ISBN: 1578700701, 1999.
  • [14] Howes T. and M. Smith, "LDAP Programming Directory-Enabled Applications with Lightweight Directory Access Protocol", New Riders Publishing, ISBN: 1578700000, 1997.

9. Relationship to Other Specifications 🦋

This specification is an RFC publication of an ITU-T publication [4], without textual changes within the standard itself (Section 4). The present section appears in the RFC publication only. To implement this specification properly, you need a bunch of standards about LDAP [1], [7], H.350 [2],[3], and SIP [4], [5], [6], [7], implemented in whole or in part by the implementor 💅

For some background on the ITU and IETF directory service protocols, reading [8], [9], [10], [11], and [12] is valuable, and [13] and [14] are recommended books 📖✨

10. Authors' Addresses ✨

okay bestie, here are the people who wrote this 🫶 three authors, each with their own little contact card. Tyler is the H.350 Editor at UNC 🎀

Tyler Johnson
Editor, H.350
University of North Carolina
Chapel Hill, NC 27599

Phone: +1.919.843.7004
EMail: Tyler_Johnson@unc.edu

Sakae is the Rapporteur for Q.4/16 at ITU-T SG16, based at Waseda University in Japan 🌸

Sakae Okubo
Rapporteur for Q.4/16, ITU-T SG16
Waseda University
YRP Ichibankan, 3-4 Hikarinooka
Yokosuka-shi, 239-0847 Japan

Phone: +81 46 847 5406
EMail: sokubo@waseda.jp

And Simao is the Counsellor for ITU-T SG 16, over at the International Telecommunication Union in Geneva 🌈

Simao Ferraz de Campos Neto
Counsellor, ITU-T SG 16
International Telecommunication Union
Place des Nations
Geneva CH1211 - Switzerland

Phone: +41-22-730-6805
EMail: simao.campos@itu.int

Copyright (C) The Internet Society (2004).

this document is totally bound by the rights, licenses and restrictions in BCP 78, plus whatever's over at www.rfc-editor.org. Except for what's set out there, the authors keep all their rights 🦋

the document and the info in it are given to you "AS IS", and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Intellectual Property 🔥

the IETF is not taking a side on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this document are valid, or how far they reach. It also doesn't say whether any license under those rights is or isn't available. And it hasn't done its own independent digging to find any of those rights either 🙈 For info on how ISOC handles rights in ISOC Documents, check BCP 78 and BCP 79.

if you disclosed IPR to the IETF Secretariat, or you're looking for assurances of licenses, or you tried to get a general license or permission to use proprietary rights as an implementer or user of this spec, you can look at the IETF's online IPR repository at http://www.ietf.org/ipr. The results of those attempts can be found there too ✨

and if you spot any copyrights, patents, patent applications, or other proprietary rights that might cover technology you'd need to implement this standard, the IETF totally wants to hear about it! Send it to ietf-ipr@ietf.org 🫶

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society 💖 thank you, ISOC, you're literally keeping the lights on ⭐

📦 where this page comes from