![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ufn.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / ufn|
Return to ufn.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / ufn |
1.1 root 1: %\documentstyle [11pt,ucl-rn-pic,tgrind,a4] {article}
2: \documentstyle [11pt,ucl-rn,tgrind] {article}
3: \author {S.E. Kille}
4: \date {June 1990}
5: \rnnumber{RN/90/29}
6: \title {Using the OSI Directory to achieve \\ User Friendly Naming}
7: \begin {document}
8: \maketitle
9: \begin {abstract}
10: The OSI Directory has user friendly naming as a goal. A simple minded usage
11: of the directory does not achieve this. Two aspects not achieved are:
12:
13: \begin{itemize}
14: \item A user oriented notation
15: \item Guessability
16: \end{itemize}
17:
18: This proposal sets out some conventions for representing names in a friendly
19: manner, and shows how this can be used to achieve really friendly naming.
20: \end {abstract}
21:
22: \tableofcontents
23: \listoffigures
24: \listoftables
25: \pagebreak
26:
27: \section {Why a notation is needed}
28:
29: Many OSI Applications make use of Distinguished Names (DN) as defined in the
30: OSI Directory \cite{CCITT.Directory}.
31: The main reason for having a notation for
32: is for interacting with a user
33: interface. This proposal is coming dangerously close to the sin of
34: standardising interfaces. However, there are aspects of presentation which
35: it is desirable to standardise.
36:
37: In very many cases, a user will be required to
38: input a name. This notation is designed to allow this to happen in a
39: uniform manner across many user interfaces. The intention is that
40: the name can just be typed in. There should not be any need to engage in
41: form filling or complex dialogue.
42:
43: A secondary goal, is to have a common
44: format to be able to unambiguously refer to names.
45: This notation should {\em not} be needed to write on business cards or in
46: the minutes of meetings. If this is the case, the directory has failed to a
47: large extent. It should be possible to take the ``human'' description given
48: at the meeting, and use it directly. The means in which this happens will
49: become clear later. In practice, it will often be useful to explicitly write
50: down directory names, even though it is not strictly needed.
51:
52: \section {A notation for Distinguished Name}
53:
54: \subsection {Goals}
55:
56: The following goals are laid out:
57:
58: \begin {itemize}
59: \item It should be intuitive for the majority of names encountered
60: \item It should be fully general
61: \item It should be possible to lay it out in a number of ways
62: \end {itemize}
63:
64: \subsection {Informal definition}
65:
66: This notation is designed to be convenient for common forms of name.
67: Some examples are given.
68: My directory (distinguished) name would be written:
69:
70: \begin{verbatim}
71: Steve Kille, Computer Science, University College London, GB
72: \end{verbatim}
73:
74: This may be folded, perhaps to display in multi-column format.
75: For example:
76:
77: \begin {verbatim}
78: Steve Kille,
79: Computer Science,
80: University College London,
81: GB
82: \end{verbatim}
83:
84: or
85:
86: \begin {verbatim}
87: Steve Kille
88: Computer Science
89: University College London, GB
90: \end{verbatim}
91:
92: Another name might be:
93:
94:
95: \begin {verbatim}
96: Christian Huitema, INRIA, FR
97: \end{verbatim}
98:
99: An example, showing how different attribute types are handled:
100:
101:
102: \begin {verbatim}
103: James Hacker
104: locality=Basingstoke
105: Widget Inc
106: GB
107: \end{verbatim}
108:
109: An example showing quoting of a comma in an Organisation name:
110:
111: \begin {verbatim}
112: L. Eagle, "Sue, Grabbit and Runn", GB
113: \end{verbatim}
114:
115:
116: \subsection {Formal definition}
117:
118:
119: The structure is specified in a BNF grammar in Figure~\ref{BNF}.
120:
121: \begin{figure}
122: \begin {verbatim}
123: <name> ::= <name-component>
124: | <name-component> <spaced-separator> <name>
125:
126: <spaced-separator> ::= <optional-space>
127: <separator>
128: <optional-space>
129:
130: <separator> ::= "," ( <CR> )
131: | <CR>
132:
133: <optional-space> ::= *( " " )
134:
135: <name-component> ::= <attribute>
136: | <attribute> <optional-space> "+" ( <CR> )
137: <optional-space> <name-component>
138:
139: <attribute> ::= <string>
140: | <key> <optional-space> "=" <optional-space> <string>
141:
142: <key> ::= 1*( <keychar> )
143: <keychar> ::= letters, numbers, and space
144:
145: <string> ::= *( <stringchar> | <pair> )
146: | '"' *( <stringchar> | "," | "+" | "=" | <CR> ) '"'
147:
148: <special> ::= "," | "=" | '"' | <CR> | "\" | "+"
149: <pair> ::= "\" <special>
150: <stringchar> ::= any char except <special>
151:
152: \end{verbatim}
153: \caption {BNF Grammar for Distinguished and Purported Name}
154: \label {BNF}
155: \end{figure}
156:
157:
158: The quoting mechanism is used for the following cases:
159:
160: \begin {itemize}
161: \item Strings containing ``,'', ``+'', ``=''or ``\verb|"|'' or \verb|<CR>|
162: \item Strings with leading or trailing spaces
163: \item Strings containing consecutive spaces
164: \end {itemize}
165:
166: A list of valid keywords for well known attribute types used in naming is
167: given in Table~\ref{keywords}. This is a list of keywords which must be
168: supported. These are chosen because they appear in common forms of name,
169: and can do so in a place which does not correspond to the default schema
170: used.
171: If other attributes are used for naming, this can always be
172: extended locally.
173:
174: \begin{table}
175: \begin{center}
176: \begin {tabular}{l l}
177: Key & Attribute (X.520 keys) \\
178: \hline
179: Locality & LocalityName \\
180: Area & LocalityName \\
181: Organisation & OrganizationName \\
182: Organization & OrganizationName \\
183: \end {tabular}
184: \end{center}
185: \caption {Standardised Keywords}
186: \label {keywords}
187: \end{table}
188:
189:
190: Only string type attributes are
191: considered, but other attribute syntaxes could be supported locally.
192: It is assumed that the interface will translate from the supplied string
193: into PrintableString or T.61.
194:
195: The \verb|"+"| notation is used to specify multi-component RDNs. In this
196: case, the types for attributes in the RDN must be explicit.
197:
198: The name is presented/input in a little-endian order. If no type are given,
199: a type hierarchy (schema) is assumed as:
200:
201: \begin {verbatim}
202: Common Name, (((Organisational Unit)*, Organisation,) Country)
203: \end{verbatim}
204:
205: Explicitly typed RDNs may be inserted into this hierarchy. Two types of
206: object are named. They are distinguished by context in the application:
207:
208: \begin{description}
209: \item[Common Name Object] Typically a leaf object and a person. In this
210: case, the LHS RDN is assumed to be common name, and other RDNs follow the
211: hierarchy.
212:
213: \item[Other Object] Typically a non-leaf object.
214: \end{description}
215:
216:
217: \section {Purported names}
218:
219:
220: A purported name is what a user supplies to an interface for resolution
221: into one or more distinguished names.
222: The same
223: notation is used as for distinguished name.
224: A purported name may differ from a distinguished name in a number of ways
225: which are itemised below.
226:
227: Typically, an
228: interface will display a distinguished name, using the distinguished name
229: notation. However, it may display a purported name, as this will be more
230: pleasing to the user. The most common example of this is where the higher
231: components of the distinguished name are not displayed (abbreviation).
232:
233: The ways in which a purported name may vary from a distinguished name are
234: now described:
235:
236: \begin {description}
237: \item[Abbreviation] Some of the more significant components of the DN will
238: be omitted, and then defaulted in some way (e.g., relative to a local
239: context). For example:
240:
241: \begin {verbatim}
242: Steve Kille
243: \end{verbatim}
244:
245: \item[Component Omission]
246: An intermediate component of the name may be omitted. Typically this will
247: be an organisational unit. For example:
248:
249: \begin {verbatim}
250: Steve Kille, University College London, GB
251: \end{verbatim}
252:
253:
254: In some cases, this can be combined with abbreviation. For example:
255:
256: \begin {verbatim}
257: Steve Kille, University College London
258: \end{verbatim}
259:
260: \item[Approximation] Approximate renditions or alternate values
261: of one or more of the components
262: will be supplied. For example:
263:
264: \begin {verbatim}
265: Stephen Kille, CS, UCL, GB
266: \end{verbatim}
267:
268: or
269:
270: \begin{verbatim}
271: Steve Keill, Comp Sci, Univarstiy College London, GB
272: \end{verbatim}
273:
274:
275: \item[Friendly Country] A ``friendly country name'' can be used instead of
276: the ISO 3166 two letter code. For example: UK; USA; France; Deutchland.
277:
278: \item[Type Changing] A type may be omitted, even where it does not follow
279: the hierarchy. Type variants can be explored.
280: The previous distinguished name:
281: \begin {verbatim}
282: James Hacker
283: locality=Basingstoke
284: Widget Inc
285: GB
286: \end{verbatim}
287:
288: Could be represented by the purported name:
289:
290: \begin {verbatim}
291: James Hacker
292: Basingstoke
293: Widget Inc
294: GB
295: \end{verbatim}
296:
297:
298: \end {description}
299:
300:
301: \section {Matching a purported name}
302:
303: The major utility of the purported name is to provide the important ``user
304: friendly'' characteristic of guessability. A user will supply a purported
305: name to a user interface, and this will be resolved onto a distinguished
306: name.
307: When a user supplies a purported name there is a need to derive the DN. In
308: most cases, it should be possible to derive a single name from the purported
309: name. In some cases, ambiguities will arise and the user will be prompted
310: to select from a multiple matches. This should also be the case where a
311: component of the name did not ``match very well''.
312:
313: There is an assumption that the user will simply enter the name correctly.
314: The purported name variants are designed to make this happen! There is no
315: need for fancy window based interfaces or form filling for many applications
316: of the directory. Note that the fancy interfaces still have a role for
317: browsing, and for more complex matching. This type of naming is to deal
318: with cases where information on a known user is desired and keyed on the
319: user's name.
320:
321: \subsection {Environment}
322:
323:
324:
325:
326: All matches occur in the context of a local environment.
327: The local environment defines a
328: sequence of name of a non-leaf objects in the DIT.
329: This environment effectively defines a list of acceptable name abbreviations
330: where the DUA is employed. It also defines an order in which to operate.
331:
332:
333: This list is defined in the context of the number of name components
334: supplied. This allows varying heuristics, depending on the environment, to
335: make the approach have the ``right'' behaviour.
336:
337:
338: In most cases, the environment will start at a local point in the DIT, and
339: move upwards. Examples are given in Tables~\ref{e1} and~\ref{e2}.
340: Table~\ref{e1} shows an example for a typical local DUA, which has the
341: following characteristics:
342:
343: \begin{description}
344: \item[One component] Assumed first to be a user in the department, then a
345: user or department within the university, the a national organisation, and
346: finally a country.
347: \item[Two components] Most significant component is first assumed to be a
348: national organisation, then a department (this might be reversed in some
349: organisations), and finally a country.
350: \item[Three or more components] The most significant component is first
351: assumed to be a country, then a national organisation, and finally a
352: department.
353: \end{description}
354:
355:
356:
357: \begin{table}
358: \begin{center}
359: \begin{tabular}{l l}
360: Number of & Environment \\
361: Components & \\
362: \hline
363: 1 & Physics, University College London, GB \\
364: & University College London, GB \\
365: & GB \\
366: & -- \\
367: \hline
368: 2 & GB \\
369: & University College London, GB \\
370: & -- \\
371: \hline
372: 3+ & -- \\
373: & GB \\
374: & University College London, GB \\
375:
376: \end{tabular}
377: \end{center}
378: \caption {Local environment for private DUA}
379: \label{e1}
380: \end{table}
381:
382: \begin{table}
383: \begin{center}
384: \begin{tabular}{l l}
385: Number of & Environment \\
386: Components & \\
387: \hline
388: 1,2 & US \\
389: & CS \\
390: & -- \\
391: \hline
392: 3+ & -- \\
393: & US \\
394: & CA \\
395: \end{tabular}
396: \end{center}
397: \caption {Local environment for US Public DUA}
398: \label{e2}
399: \end{table}
400:
401:
402: \subsection {Matching}
403:
404:
405: A purported name will be supplied, usually with a small number of components.
406: This will be matched in the context of an environment.
407:
408: Where there are multiple components to be matched, these should be matched
409: sequentially. If an unambiguous DN is determined, the match continues as if
410: the full DN had been supplied.
411: For example if
412:
413: \begin{quote}
414: \begin{verbatim}
415: Stephen Kille, UCL
416: \end{verbatim}
417: \end{quote}
418:
419: is being matched in the context of environment \verb|GB|, first \verb|UCL|
420: is resolved to the distinguished name:
421:
422: \begin{quote}
423: \begin{verbatim}
424: University College London, GB
425: \end{verbatim}
426: \end{quote}
427:
428: Then the next component of the purported name is taken to determine the
429: final name.
430: If there is an ambiguity (e.g., if \verb|UCL| had made two matches,
431: both paths are explored to see if the ambiguity can
432: be resolved. Eventually a set of names will be passed back to the user.
433:
434:
435: Each component of the environment is taken in turn.
436: If the purported name has more
437: components than the maximum depth, the environment element is skipped.
438: The advantage of this will be seen in the example given later.
439:
440:
441:
442:
443:
444:
445: A match of a name is considered to have three levels:
446:
447: \begin{description}
448: \item[Exact] A DN is specified exactly
449: \item[Good]
450: Initially, a match should be considered good if
451: it is unambiguous, and exactly matches an attribute value in the entry.
452: For human names, a looser metric is probably desirable (e.g., \verb|S Kille|
453: should be a good match of \verb|S. Kille|, \verb|S.E. Kille| or \verb|Steve
454: Kille| even if these are not explicit alternate values).
455: \item[Poor] Any other substring or approximate match
456: \end{description}
457:
458: Following a match, the reference can be followed, or the user prompted.
459: If there are multiple matches, more than one path may be followed.
460: There is also a shift/reduce type of choice: should any partial matches be
461: followed or should the next element of the environment be tried.
462: The following heuristics are suggested, which may be modified in the light
463: of experience. The overall aim is to resolve cleanly specified names with a
464: minimum of fuss, but give sufficient user control to prevent undue searching
465: and delay.
466:
467: \begin{enumerate}
468: \item Always follow an exact match.
469: \item Follow all good matches if there are no exact matches.
470: \item If there are only poor matches, prompt the user. If the user accepts
471: one or more match, they can be considered as good. If all are rejected,
472: this can be treated as no matches.
473: \item Automatically move to the next element of the environment if no
474: matches are found.
475: \end{enumerate}
476:
477: When the final component is matched, a set of names will be identified.
478: If none are identified, proceed to the next environment element.
479: If the user rejects all of the names, processing of the next environment
480: element should be confirmed.
481:
482: The exact approach to matching will depend on the level of the tree at which
483: matching is being done.
484: We can now consider how attributes are matched at various levels of the DIT.
485:
486:
487: There is an issue of approximate matching. Sometimes it helps, and
488: sometimes just returns many spurious matches. When a search is requested,
489: all relevant attributes should be returned, so that distinguished and
490: non-distinguished values can be looked at. This will allow a distinction to
491: be made between good and poor matches. It is important that where, for
492: example, an acronym exactly matches an organisation, that the user is not
493: prompted about other organisations where it matches as a substring.
494:
495: \subsection {Top Level}
496:
497: In this case, a match is being done at the root of the DIT.
498: Three approaches are suggested, dependent on the length of supplied name.
499: All lead to a single level search of the top level of the DIT.
500:
501: \begin{description}
502: \item[Exactly 2] This is assumed to be a 3166 two letter country code, or an exact
503: match on a friendly country or organisation (e.g., UK or UN).
504: Do exact match on country and friendly country.
505: \item[Greater than 2] Make
506: an approximate and substring match on friendly country and organisation.
507:
508: \end{description}
509:
510:
511:
512:
513:
514:
515: \subsection {Intermediate Level}
516:
517: Once the root level has been dealt with, intermediate levels will be looking
518: for organisational components (Organisation, Locality, Org Unit).
519: In some cases, private schema control will allow the system to determine
520: which is at the next level. In general this will not be possible.
521: In each case, make a substring and approximate match search of one level.
522: The choice depends on the base object used in the search.
523:
524: \begin {enumerate}
525: \item If DN has no Organisation or Locality, filter on Organisation and
526: Locality.
527: \item If DN has Org Unit, filter on Org Unit.
528: \item If DN has Organisation, filter on Locality and Org Unit.
529: \item If DN has Locality, filter on Organisation.
530: \end {enumerate}
531:
532: These allow some optimisation, based on legal choices of schema. Keeping
533: filters short is usually desirable to improve performance.
534:
535: A few examples of this, where a base object has been determined (either by
536: being the environment or by partial resolution of a purported name), and the
537: next element of a purported name is being considered. This will generate a
538: single level search. What varies is the types being filtered against.
539: If the DN is:
540:
541: \begin{verbatim}
542: University College London, GB
543: \end{verbatim}
544:
545: The search should be for Org Unit or Locality. If the DN is:
546:
547: \begin{verbatim}
548: Organisation=UN
549: \end{verbatim}
550:
551: the search should be for Org Unit or Locality.
552:
553: There may be some improvements with respect to very short keys. Not making
554: approximate or substring matches in these cases seems sensible\footnote{It
555: might be desirable to allow ``\verb|*|'' as a part of the purported name
556: notation}.
557:
558: \subsection {Bottom level}
559:
560: The ``Bottom Level'' is to deal with leaf entries in the DIT. This will
561: often be a person, but may also be a role, an application entity or
562: something else.
563:
564: The last component of a purported name may either reference a leaf or
565: non-leaf. For this reason, {\em both} should be tested for.
566: As a heuristic, if the base object for the search has two or more
567: components it should be tested first as a bottom level name and then
568: intermediate. Reverse this for shorter names. This optimises for the
569: (normal) case
570: of non-leaves high up the tree and leaves low down the tree.
571:
572: For bottom level names, make an
573: approximate and substring match against Common Name, Surname, and User ID.
574: Where common name is looked for,
575: A full subtree search will be used when at
576: the second level of the DIT or lower, otherwise a single level search.
577:
578: For example, if I have resolved a purported name to the distinguished name
579:
580: \begin{verbatim}
581: University College London, GB
582: \end{verbatim}
583:
584: and have a single component \verb|Bloggs|, this will generate a subtree
585: search.
586:
587: \section{Examples}
588:
589:
590: This is all somewhat confusing, and a few examples are given. These are all
591: in the context of the environment shown in Table~\ref{e1} on
592: Page~\pageref{e1}.
593:
594: If ``Joe Bloggs'' is supplied, a subtree search of
595:
596: \begin{verbatim}
597: Physics, University College London, GB
598: \end{verbatim}
599:
600: will be made, and the user prompted for ``Joseph Z. Bloggs'' as the only
601: possible match.
602:
603: If ``Computer Science'' is supplied, first
604:
605: \begin{verbatim}
606: Physics, University College London, GB
607: \end{verbatim}
608:
609: will be searched, and the user will reject the approximate match of ``Colin
610: Skin''. Then a subtree search of
611:
612: \begin{verbatim}
613: University College London, GB
614: \end{verbatim}
615:
616: will be made, looking for a person. Then a single level search will be made
617: looking for Org Unit, and
618:
619: \begin{verbatim}
620: Computer Science, University College London, GB
621: \end{verbatim}
622:
623: will be returned without prompting (exact match).
624:
625:
626: Supplying ``Steve Kille'' will lead to a failed subtree search of
627:
628: \begin{verbatim}
629: Physics, University College London, GB
630: \end{verbatim}
631:
632: and lead straight to a subtree search of
633:
634: \begin{verbatim}
635: University College London, GB
636: \end{verbatim}
637:
638: This will lead to an exact value match, and so a single entry returned
639: without prompting.
640:
641:
642: If ``Andrew Findlay, Brunel'' is supplied, the first element of the
643: environment will be skipped, single level search of ``Brunel'' under ``GB'
644: will find:
645:
646: \begin{verbatim}
647: Brunel University, GB
648: \end{verbatim}
649:
650: and a subtree search for ``A Findlay'' initiated. This will yield
651:
652: \begin{verbatim}
653: Andrew Findlay, Computing and Media Services, Brunel University, GB
654:
655: Dr A J Findlay, Manufacturing and Engineering Systems,
656: Brunel University, GB
657: \end{verbatim}
658:
659:
660: and the user will be prompted with a choice.
661:
662:
663: This approach shows how a simple format of this nature will ``do the right
664: thing'' in many cases.
665:
666: \section {Support required from the standard}
667:
668: Fortunately, all that is needed is there! It would be useful to have
669: ``friendly country name'' as a standard attribute.
670:
671:
672: \section{Support of OSI Services}
673:
674: The major focus of this work has been to provide a mechanism for identifying
675: Organisations and Users. A related function is to identify applications.
676: Where the Application is identified by an AET (Application Entity Title)
677: with an RDN of Common Name, this proposal leads to a natural usage.
678: For example, if a filestore in named ``gannet'', then this could easily be
679: identified by the name:
680:
681: \begin{verbatim}
682: Gannet, Computer Laboratory, Cambridge University, GB
683: \end{verbatim}
684:
685: In normal usage, this might lead to access (using a purported name) of:
686:
687: \begin{verbatim}
688: FTAM gannet,cambridge
689: \end{verbatim}
690:
691: A second type of access is where the user identifies an Organisation
692: (Organisational Unit), and expects to obtain a default service.
693: The service is implied by the application, and should not require any
694: additional naming as far as the user is concerned. It is proposed that this
695: is supported by User Friendly Naming in the following way.
696:
697: \begin{enumerate}
698: \item Determine that the purported name identifies a non-leaf object, which is
699: of object class Organisation or Organistaional Unit or Locality.
700:
701: \item Perform a {\em single level} search for Application Entities which
702: support the required application contexts. This assumes that all services
703: which are supporting default access for the organisation are registred at
704: one level below (possibly by the use of aliaes), and that other services
705: (specific machines or parts of the organisation) are represented further
706: down the tree. This seems to be a reasonable layout, and its utility can be
707: evaluated by experiment.
708:
709: \end{enumerate}
710:
711: \section {Experience}
712:
713: An experimental implementation of this has been written by Colin Robbins.
714: The example in Figure~\ref{usage} shows that it can be very effective at
715: locating known individuals with a minimum of effort.
716:
717: \begin{figure}
718: \begin{small}
719: \begin{verbatim}
720: -> t hales, csiro, australia
721: Found good match(es) for 'australia'
722: Found exact match(es) for 'csiro'
723: Please select from the following:
724: Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y
725: The following were matched...
726: Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU
727:
728: -> g michaelson, queensland, au
729: Found exact match(es) for 'au'
730: Please select from the following:
731: University of Queensland, AU [y/n] ? y
732: Axolotl, AU [y/n] ? n
733: Please select from the following:
734: George Michaelson, Prentice Computer Centre, University of Queensland, AU
735: [y/n] ? y
736: Manager, University of Queensland, AU [y/n] ? n
737: The following were matched...
738: George Michaelson, Prentice Computer Centre, University of Queensland, AU
739:
740: -> r needham, cambridge
741: Found good match(es) for 'cambridge'
742: Please select from the following:
743: Roger Needham, Computer Lab, Cambridge University [y/n] ? y
744: The following were matched...
745: Roger Needham, Computer Lab, Cambridge University
746:
747: -> kirstein
748: Found good match(es) for 'kirstein'
749: The following were matched...
750: Peter Kirstein
751:
752:
753: \end{verbatim}
754: \end{small}
755: \caption {Example usage of User Friendly Naming}
756: \label{usage}
757: \end{figure}
758:
759:
760: \section {Relationship to other work}
761:
762: Colin Robbin's work on the interface ``Tom'' and implementation of a
763: distribution list interface strongly influenced this proposal.
764:
765: Some of the ideas used here originally came from a UK Proposal to the
766: ISO/CCITT Directory Group on ``New Name Forms'' \cite{NNF}. This defined,
767: and showed how to implement, four different types of names:
768:
769: \begin{description}
770: \item[Typed and Ordered] The current Distinguished Name is a restricted
771: example of this type of name.
772:
773: \item[Untyped and Ordered] This is the type of name proposed here (with some
774: extensions to allow optional typing). It is seen as meeting the key user
775: requirement of disliking typed names, and is efficient to implement.
776:
777: \item[Typed and Unordered] This sort of name is proposed by others as the
778: key basis for user friendly naming. Neufeld shows how X.500 can be used to
779: provide this \cite{Neufeld.Descr}, and Peterson proposes the Profile system
780: to provide this \cite{Profile.2}. The author contends that whilst typed
781: naming is interesting for some types of searching (e.g., yellow page
782: searching), it is less desirable for
783: naming objects. This is born out by operational experience with OSI
784: Directories \cite{THORN.RARE.LSPX}.
785:
786: \item[Untyped and Unordered] Surprisingly this form of name can be supported
787: quite easily. However, a considerably gain in efficiency can be achieved by
788: requiring ordering. In practice, users can supply this easily. Therefore,
789: this type of name is not proposed.
790: \end{description}
791:
792:
793: \section {Proposal}
794:
795: This approach should be tested out experimentally, with the QUIPU
796: implementation. This will involve:
797:
798: \begin{itemize}
799: \item An interface to generate strings in this form from DNs, with control over
800: \begin{itemize}
801: \item Folding (line, column, or max width)
802: \item Presence of commas at EOL
803: \item A DN to be abbreviated against
804: \end{itemize}
805:
806: \item A routine to resolve a purported name in the context of an environment.
807: \end{itemize}
808:
809: The Distribution List interface seems to be an ideal system to experiment
810: with.
811:
812: A specification should then be progressed, and made widely available.
813: Perhaps as a RARE Document or RFC.
814:
815: \bibliographystyle{alpha}
816: \bibliography{../../bib/sek}
817:
818: \pagebreak
819: \appendix
820:
821: \section{Pseudo-code for the matching algorithm}
822:
823: The following pseudo-code is intended to clarify the matching algorithm.
824: The language uses ASN.1 data types, with flow control `C'-like, but with
825: keywords upper--cased.
826:
827: \tagrindfile{algo}{Matching Algorithm}{algo}
828:
829:
830:
831: \end {document}
832:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.