Using the OSI Directory to Achieve User Friendly Naming
RFC 1781

Document Type RFC - Historic (March 1995; No errata)
Obsoleted by RFC 3494
Obsoletes RFC 1484
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
This information refers to IESG processing after the RFC was initially published:
IESG IESG state RFC 1781 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Patrik Fältström
Send notices to <vijay@cosinecom.com>, <pacew@us.ibm.com>, <anoop@raleigh.ibm.com>
Network Working Group                                           S. Kille
Request for Comments: 1781                              ISODE Consortium
Obsoletes: 1484                                               March 1995
Category: Standards Track

        Using the OSI Directory to Achieve User Friendly Naming

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The OSI Directory has user friendly naming as a goal.  A simple
   minded usage of the directory does not achieve this.  Two aspects not
   achieved are:

    o  A user oriented notation

    o  Guessability

   This proposal sets out some conventions for representing names in a
   friendly manner, and shows how this can be used to achieve really
   friendly naming.  This then leads to a specification of a standard
   format for representing names, and to procedures to resolve them.
   This leads to a specification which allows directory names to be
   communicated between humans.  The format in this specification is
   identical to that defined in [5], and it is intended that these
   specifications are compatible.

Table of Contents

   1.   Why a notation is needed ...................................   2
   2.   The Notation ...............................................   3
   3.   Communicating Directory Names ..............................   7
   4.   Matching a purported name ..................................   9
       4.1    Environment ..........................................   9
       4.2    Matching .............................................  10
       4.3    Top Level ............................................  12
       4.4    Intermediate Level ...................................  13
       4.5    Bottom Level .........................................  14
   5.   Examples ...................................................  14
   6.   Support required from the standard .........................  15

Kille                                                           [Page 1]
RFC 1781                  User Friendly Naming                March 1995

   7.   Support of OSI Services ....................................  15
   8.   Experience .................................................  16
   9.   Relationship to other work .................................  17
   10.  Issues .....................................................  19
   11.  References .................................................  20
   12.  Security Considerations ....................................  21
   13.  Author's Address ...........................................  21
   A.   Pseudo-code for the matching algorithm .....................  22
   List of Figures
       1.     Example usage of User Friendly Naming ................  18
       2.     Matching Algorithm ...................................  22
   List of Tables
       1.     Local environment for private DUA ....................  10
       2.     Local environment for US Public DUA ..................  11

1.  Why a notation is needed

   Many OSI Applications make use of Distinguished Names (DN) as defined
   in the OSI Directory [1].  The main reason for having a notation for
   name format is to interact with a user interface.  This specification
   is coming dangerously close to the sin of standardising interfaces.
   However, there are aspects of presentation which it is desirable to
   standardise.

   It is important to have a common format to be able to conveniently
   refer to names.  This might be done to represent a directory name on
   a business card or in an email message.  There is a need for a format
   to support human to human communication, which must be string based
   (not ASN.1) and user oriented.

   In very many cases, a user will be required to input a name.  This
   notation is designed to allow this to happen in a uniform manner
   across many user interfaces.  The intention is that the name can just
   be typed in.  There should not be any need to engage in form filling
   or complex dialogue.  It should be possible to take the "human"
   description given at the meeting, and use it directly.  The means in
   which this happens will become clear later.

   This approach uses the syntax defined in [5] for representing
   distinguished names.  By relaxing some of the constraints on this
   specification, it is argued that a more user oriented specification
   is produced.  However, this syntax cannot be mapped algorithmically
   onto a distinguished name without the use of a directory.

   This notation is targeted towards a general user oriented system, and
   in particular to represent the names of humans.  Other syntaxes may
Show full document text