Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))
RFC 1484

Document Type RFC - Historic (July 1993; No errata)
Obsoleted by RFC 1781, RFC 3494
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1484 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                               S. Hardcastle-Kille
Request for Comments: 1484                             ISODE Consortium
                                                              July 1993

                   Using the OSI Directory to achieve
                          User Friendly Naming
                           (OSI-DS 24 (v1.2))

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" 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 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 [HK93], and it is intended that these specifications
   are compatible.  Please send comments to the author or to the
   discussion group: <osi-ds@CS.UCL.AC.UK>.

Hardcastle-Kille                                                [Page 1]
RFC 1484                  User Friendly Naming                 July 1993

Table of Contents

   1.  Why a notation is needed......................................  2
   2.  The Notation..................................................  3
   3.  Communicating Directory Names.................................  8
   4.  Matching a purported name.....................................  9
   4.1 Environment................................................... 10
   4.2 Matching...................................................... 12
   4.3 Top Level..................................................... 13
   4.4 Intermediate Level............................................ 14
   4.5 Bottom Level.................................................. 15
   5.  Examples...................................................... 15
   6.  Support required from the standard............................ 16
   7.  Support of OSI Services....................................... 16
   8.  Experience.................................................... 17
   9.  Relationship to other work.................................... 18
   10. Issues........................................................ 19
   11. References.................................................... 20
   12. Security Considerations....................................... 21
   13. Author's Address.............................................. 21
   A.  Pseudo-code for the matching algorithm ....................... 21

List of Figures

   1. Example usage of User Friendly Naming.......................... 18
   2. Matching Algorithm............................................. 25

List of Tables

   1. Local environment for private DUA.............................. 11
   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 [CCI88].  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.

Hardcastle-Kille                                                [Page 2]
RFC 1484                  User Friendly Naming                 July 1993

   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 RFC1485 for representing
   distinguished names [HK93].  By relaxing some of the constraints on
   this specification, it is argued that a more user oriented
Show full document text